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

Разрушители легенд: приоритеты и сроки инцидентов

Опубликовано 27 марта 2011
Рубрики: ITIL, ITSM, Технологии, автоматизация, ПО для ITSM, Управление инцидентами
Комментарии

Внимательно читаем ISO 20000 и не перестаем удивляться. Часть 2, страница 20, черным по белому: "Targets for resolution should be based on priority." Мне неизвестно, откуда взята эта рекомендация (в ITIL я такого утверждения не помню). И хорошо, что не в первой части стандарта (то есть не требование, а рекомендация).

И так, легенда: срок инцидента должен рассчитываться на основании приоритета.

В моем понимании это – широко распространенное заблуждение и пример серьезного непонимания модели определения приоритета на основании уровня влияния и срочности, описанной в ITIL. По идее приоритезация работ (любых, не только устранения инцидентов) должна способствовать своевременности их исполнения. Однако расчет сроков на основании приоритетов – эту идею "убивает". Подробнее об этом можно почитать здесь: https://cleverics.ru/services/omnitracker/180-using-priorities. Таким образом, расчет срока на основании приоритета существенно снижает ценность приоритезации вообще.

К сожалению, многие программные продукты работают именно так – срок рассчитывается по приоритету. Из "молодцов" могу вспомнить только Remedy ITSM Suite. Гибкость продукта такова, что Service targets могут "привязываться" не только к приоритету, но и к уровню влияния, и к другим параметрам (само по себе это, впрочем, ничего не гарантирует, поскольку за выбор правильного способа расчета сроков в данном случае отвечает внедренец). И к сожалению я совсем не помню как этот функционал реализован в Assyst'е. Подскажите, кто знает, пжл.

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

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

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

    Еще HPOVSD45 подкручивая, основой соответствия делали Услуга + Тип заявки, что выросло через пару лет вот в это:
    http://www.itsmforum.ru/reference/publication/article_16
    “Схема, рекомендуемая ITIL2 и ITIL3, вообще не работает и не будет работать в подавляющем большинстве организаций по причине высокого уровня необъективности, заложенной в ней изначально!”

    Снова мыслим в одну сторону? 😉

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

      “Снова мыслим в одну сторону?”

      Похоже на то. Причем в одно и то же время – я тоже “переживал” эту тему в 2008. Тогда же эти мысли легли в наши курсы. Сейчас – это стандартная часть курса по саппорту от Cleverics. Я и вспомнил-то о ней исключительно из-за ISO 20000 – пришлось тут читать и вспоминать.

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

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

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

        Ну слава богу, а то я уж начал сомневаться, все ли нормально в этом мире! 8)

        А если серьезно – то я твою заметку по ссылке раньше читал: интересно, спорно-обсуждаемо. Но сходимся в главном – предлагаемая схема itil2-3 неясно для кого придумана.

        • Евгений Шилов

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

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

            Евгений, а это больше похоже на описываемую мной схему.

            У меня: смотри на срок, получишь приоритет.
            У Димы: подходит срок – поднимай приоритет.

            Но всяко “обе лучше”, чем приоритет = срочность + влияние.

            • Евгений Шилов

              “приоритет = срочность + влияние” и правда странно.

              Но я то про свое: зачем он вообще нужен, этот приоритет, если на него никто не смотрит 🙂
              Зачем его поднимать, получать, если в голове человек все равно ориентируется на срок.

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

                >Но я то про свое: зачем он вообще нужен, этот приоритет, если на него никто не смотрит

                А это к Диме, к Диме.

                Евгений, в моей-то старой статье ровно это и утверждается:
                “Хорошей стоит признать практику ориентироваться при определении порядка работ по времени, оставшемуся до крайнего срока исполнения (аналогичная прямая рекомендация в ITIL не найдена)” (с)

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

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

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

                “Но я то про свое: зачем он вообще нужен, этот приоритет, если на него никто не смотрит”

                А я про свое: зачем нужны такие процессы и такие управленцы, у которых никто на приоритет не смотрит?

                Ведь любая перегрузка (задач больше, чем ресурсов) требует приоритезации. А теперь давай спросим ИТ-менеджеров – у Вас ребята как с ресурсами – с запасом, нормально? И 100% скажут – туго, не хватает. Это конечно не значит, что на самом деле не хватает. Но если при таком ответе руководитель недоумевает по поводу необходимости приоритетов, это вызывает сомнение в его компетентности.

                • Евгений Шилов

                  Эк ты категорично 🙂

                  Руководитель может и не недоумевает, и с “компетентностью” все отлично, и очень даже счастлив от того, что есть поле “приоритет”. Но вот только специалисты, которые работают и решают конкретные задачи и с которых спрашивают за сроки решения инцидентов могут быть другого мнения.
                  В итоге для них поле приоритет становится вспомогательным/информационным, которое они могут принимать во внимание, а могут не принимать, спросят с них за соблюдение сроков в первую очередь.
                  Вот если они просрочат высокоприоритетный инцидент из-за того, что занимались другими – менее приоритетными задачами, тогда конечно может и влетит, но тоже вопрос.

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

                    Ну что ж, давай разбираться по-порядку.

                    1. “Руководитель может и не недоумевает, и с «компетентностью» все отлично, и очень даже счастлив от того, что есть поле «приоритет». Но вот только специалисты, которые работают и решают конкретные задачи и с которых спрашивают за сроки решения инцидентов могут быть другого мнения.”

                    Открываем ISO 19011 “Руководящие указания по аудиту систем менеджмента качества и/или систем экологического менеджмента”. Раздел 3 “Термины и определения”. Читаем: Компетентность – продемонстрированные личные качества и _способность_применять_ свои знания и умения.

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

                    2. “Но я то про свое: зачем он вообще нужен, этот приоритет, если на него никто не смотрит”

                    С моей точки зрения это не свидетельство ненужности приоритета. Выше попытался объяснить почему.

                    Что тебя смущает?

                    • Евгений Шилов

                      Ничего не смущает, за руководителей переживаю 🙂

                      У них специалисты работой заняты, все в срок решают, правда не в том порядке, в котором система приоритеты расставляет, а их подозревают в некомпетентности 🙂

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

                      Какая идиллия. Все работают, все в срок. И правда, зачем хорошим людям приоритетами мешать? 😉

  • Андрей Сысуев

    Приоритет – приоритетность – первенство…
    Чем выше приоритет инцидента, тем выше должно быть внимание к обработке данного инцидента, он чаще должен попадаться на глаза сотрудникам поддержки. При этом срок решения, как мне кажется, на это никак не влияет.

    P.S.: в assyst’e приоритет не связан со сроком. Там на приоритет можно завязать количество эскалаций по инциденту и порядок работы с ними.

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

      А как определяется срок решения заявки?

      • Андрей Сысуев

        Срок решения заявки определяет параметр “Срочность”, а он может зависеть от очень многих факторов, не говоря о ручном выборе.

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

          А как связаны приоритет и срочность?

          • Андрей Сысуев

            стандартно – никак.
            Наборы обоих параметров разрабатываются совместно для дальнейшей согласованной работы

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

              Забавно. А говорят – у нас все по ITIL 😉

              • Андрей Сысуев

                ITIL не всегда безупречен и подробен

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

                  Я-то не возражаю. Зачем же тогда утверждать, что “У нас все по ITIL”, если он “не всегда безупречен и подробен”? 😉

                  • Андрей Сысуев

                    это славное слово маркетинг:))

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

                      Приветствую, коллеги, немного уточню по assyst.
                      Каждый объект (inc, prb, chg) имеет две характеристики: Seriousness и Priority.

                      SLA каждому инциденту может назначаться в зависимости практически от любого справочника (пользователь, CI, здание, оргединица и т.д.).
                      SLA имеет две настройки: Resolution и Escalation.
                      В Resolution прописываются целевые сроки решения, по каждому из значений Seriousness.
                      В Escalation прописываются сроки эскалации (т.е. промежутки времени, прошедшие с момента создания объекта, по достижению которых уровень эскалации поднимется) и уведомляемого на данном уровне сотрудника, по каждому значению Priority.

                      То есть, если коротко: с терминами у assyst везде очень туго, но даже последние официальные критерии APMG на software assessment по IM он, мне кажется, проходит (http://www.itil-officialsite.com/News/ITIL_Software_Scheme_Mandatory_Assessment_Criteria.asp)
                      Так что схема assyst кажется мне ближе к CleverENGINE, чем к HP OV =)
                      Срок решения автоматически не пересчитывается, но уровень эскалации назначенных сотруднику задач растёт и может помочь ему в выставлении *персональной* очереди исполнения.

                      Лично я придерживаюсь точки зрения, что соблюдение сроков решения инцидента никогда не является личной ответственностью исполнителя, но является показателем жизнеспособности процесса.

  • Кирилл Федулов

    Опыт показывает, что приоритет для большинства – вторичен (от части в виду описанной проблемы). И здесь, лично я, вынужден согласиться с Александром.

    На мой взгляд мы сами для себя ограничиваем области применимости различных схем, “очерчивая” подобным образом какие-то виртуальные границы.

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

    Иначе получаем автоматизацию для процессов, а не процессы для автоматизации

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

      С++, как средство автоматизации подойдет? Там можно все. Любые схемы. И связывать, и не связывать. И непосредственно, и опосредованно.

      Байки:

      1. Два года назад я купил сумку. Обычную, чтобы ноутбук таскать. До этого тоже было несколько. У всех лямка через плечо всячески крутилась и переворачивалась. Чтобы настраивать. А у этой – нет, фиксированное положение. Но удобное. Не надо ничего крутить – она висит как надо. Это моя любимая сумка (и на всякий случай – дорогая как собака, т.е. “не крутится” не от бедности).

      2. Ходят слухи, что на некоторых ранних альфах (имею ввиду Alpha Romeo, по-моему речь шла о 156) не настраивался угол наклона спинки водительского сиденья. Потому что был установлен оптимальным для вождения образом (чтобы не ездили лежа).

      Я к чему. Не к тому, что надо раз и навсегда задать жесткую схему. А к тому, что хороший софт не просто “умеет всяко”, а задает определенные лучшие практики (простите за банальность). Не согласны?

      • Андрей Сысуев

        +1
        Не вижу никакого смысла в каждом проекте изобретать велосипед (в таких простых вещах), а использовать эти самые лучшие практики:)

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

          Ага. Тут только важно не скатиться до уровня “использовать те практики, которые заложены в ПО, всем выдавая их за лучшие” 🙂

          • Андрей Сысуев

            согласен.
            Только что в этом случае считать “лучшим” большой вопрос…

      • Кирилл Федулов

        Отчего же?! Согласен, что софт должен задавать определенные лучшие практики, но именно практики, а не одну конкретную практику. При этом, конечно, ограничивать возможности он в любом случае должен (помню это уже здесь как-то обсуждали) и вполне себе жестко

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

          Да, конечно. Правда, я пока не встречал таких инструментов, которые предлагали бы одновременно несколько лучших практик в каком-то одном фрагменте функционала. Например, несколько лучших практик по расчету срока. Вы пример можете привести?

          • Кирилл Федулов

            По расчету исключительно сроков или сроков и приоритетов, которые могут быть в том числе связаны? 🙂 Если сроков, то могу, если сроков и приоритетов, то сходу не припоминаю

  • Павел Солопов

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

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

    Поэтому связка срочность+влияние=приоритет, отчасти оправдана, хотя конечно правильнее было бы применять связку влияние=срочность=приоритет.

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

      “хотя конечно правильнее было бы применять связку влияние=срочность=приоритет”

      Павел, поясните мысль… (угрожающая пауза) пожалуйста 🙂

      • Павел Солопов

        Может так будет понятней:
        влияние=>срочность=>приоритет

        Т.е. чем сильнее влияете инцидент на деятельность предприятия (ну или чего-то там ещё), тем срочнее его надо решить, чем срочнее надо решить инцидент, тем выше у него должен быть приоритет.

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

          Тут есть два момента.

          1. Пост не про то, как определять приоритет, а про то, как определять срок, и в частности как срок “завязан” на приоритет.

          2. Зачем такая сложная цепочка: “влияние=>срочность=>приоритет”? Почему нельзя проще: “влияние=>приоритет”, как сделано в HPOVSD? Зачем вводить еще один промежуточный параметр “Срочность”?

          • Павел Солопов

            Я же уточнил, что я уже утерял ход мысли, поэтому возможно не совсем в тему высказался. 🙂

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

            А вот в SD как раз таки всё наоборот, насколько я помню. Из влияния определяется приоритет, а из приоритета уже крайний срок. И в этой схеме лишним оказывается уже приоритет.

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

    Вот любопытная сводка по алгоритмам расчета приоритета и срока решения инцидентов в разных продуктах.

    BMC Remedy ITSM Suite (SLM), HP Service Manager
    ———————————————–
    Priority = f(Impact, Urgency)
    SLT/SLO = f(Много разных параметров)
    Непосредственного расчета Deadline – нет (необходима доработка).

    Axios Assyst
    ————
    Priority – независимый параметр
    Seriousness – независимый параметр (аналог Impact’а)
    SLA = f(Много разных параметров)
    Resolution = f(SLA, Seriousness)
    Escalation = f(SLA, Priority)

    HP OpenView Service Desk
    ————————
    Servicecall Priority = f(Customer, Service, Impact)
    Servicecall Deadline = f(Priority)
    Incident Priority = f(Связи между CI и услугами, Impact)
    Incident Deadline = f(Priority)

    OMNITRACKER ITSM Center
    ———————–
    Priority = f(Impact, Urgency)
    Deadline = f(Configuration item, Priority)

    OMNITRACKER CleverENGINE
    ————————
    Priority = f(Impact, Urgency)
    Servicecall Deadline = f(Customer, Service, Request type, Impact)
    Incident Deadline = f(Configuration item, Impact)

    IBM Tivoli Service Request Manager
    ———————————-
    Priority = f(Impact, Urgency)
    SLT = f(Много разных параметров)

    Если где-то наврал, поправляйте.

  • Кирилл Федулов

    Дмитрий, спасибо за информацию. Для полноты картины добавлю формулу для Naumen Service Desk:

    Priority = f (Impact, Urgency) or f (Service, Request type) or f (Configuration Item Impact, Urgency) or f (any parametres) – требует доработки

    Deadline в общем случае = f (Priority, SLA) и = f (Priority, Impact, SLA) в случае, когда Priority != f (Impact, Urgency) или != f (Configuration Item Impact, Urgency).

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

      “or f (any parametres) — требует доработки”

      Это нечестно, так все могут написать 😉 А в остальном – спасибо.

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

      Я почему-то у клиентов Naumen видел только одну схему определения срока: Срок = f(Критичность инцидента, Потребитель услуги). Я ошибаюсь? Или другие, приведенные Вами варианты возможны, но редко используются? Критичность инцидента – это аналог уровня влияния (Impact) или приоритета (Priority)?

      • Кирилл Федулов

        Дмитрий, у меня есть стойкое ощущение, что клиенты, с которыми Вы общались используют очень древнюю версию 3.2 или еще более раннюю (отзывы и понимание функциональности идет от туда же). У нас очень многое изменилось 😉
        Оттуда и описанная схема определения срока (сейчас такая схема тоже есть, но для очень специфичной “сборки”). В текущих версиях критичность есть аналог Impact (инцидента, запроса ли на обслуживание, КЕ, SLA, чего-то еще не так важно). Связь приоритета с критичностью тоже может быть разной и я ее концептуально попробовал описать.
        p.s. про “any parametres” я выделил специально, потому что это честно, мы это делаем в рамках проектов и достаточно быстро. Сомневаюсь, что этим могут похвастаться “все” 🙂

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

          1. “клиенты, с которыми Вы общались используют очень древнюю версию 3.2”
          А можете грубо в процентах оценить долю клиентов, которые перешли с “древней” версии 3.2 на более новые, “где уже все хорошо”? Может быть это и даст ответ почему мне так “не везет”.
          2. “про «any parametres» я выделил специально, потому что это честно, мы это делаем в рамках проектов и достаточно быстро. Сомневаюсь, что этим могут похвастаться «все»”
          Похвастаться?? Я Вас умоляю. Похвастаться могут все 😉

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

    В борьбе со спамом мы закрыли возможность комментировать посты, которым больше 30 дней. Однако вопросы бывают такие, что хочется вернуться к обсуждению. Например, Андрей добавил вот такие вопросы к теме:
    ————————————-
    Непонятно, как у типового запроса “Активация услуги Рабочее место” (целевое время выполнения по SLA = 3 рабочих дня) может вообще изменяться приоритет? Для любого приоритета указанный Service Request должен быть выполнен в срок до 3 рабочих дней, именно так будет запрограммировано в соответствующем SLA в системе Service Desk. Инициатор запроса может повышать срочность сколько угодно (и соответственно приоритет), но целевое время – 3 рабочих дня останется неизменным.

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

    Также вопрос – почему влияние (Impact) для такого типового запроса указано как “Нет влияния”? Запрос касается выхода нового сотрудника, значит влияние будет “1 сотрудник”.
    ———————
    Продолжим дискуссию?

    • Евгений Шилов

      Идея изменения приоритета заключается в следующем: Deadline обращения остается фиксированным. А вот приоритет, как подсказка, за что браться в первую очередь, возрастает по мере приближения к Deadline.
      Таким образом мы упрощаем жизнь специалистам автоматизируя расстановку приоритетов.
      Не всякой системе автоматизации это под силу. Например, использование штатного поля “приоритет” в HPOVSD в такой схеме невозможно, т.к. на приоритет завязана длительность в соответствии с уровнем ИТ-сервиса и SLA. Поэтому для решения такой задачи в HPOVSD можно использовать свое поле.
      На вопрос про влияние могу сказать следующее – для запросов на обслуживание (подключение к интернет, создание почтового ящика и т.д.) действительно имеет смысл устанавливать Impact “нет влияния”, т.к. нарушения в работе ИТ-сервисов при этом не наблюдается. Для того чтобы избежать путаницы стоит разделить для себя понятия “инцидент” и “запрос на обслуживание”. Упрощенно: “инцидент” – что-то сломалось, “запрос на обслуживание” – все работает, но надо что-то поделать :).

  • Isenschtill

    Коллеги, прочитал ваши споры. Весьма интересно вас спросить.
    Как вы смотрите на то, чтобы рассчитывать приоритет следующим образом:

    Priority=Urgency*Impact*T*t
    T-срок для события по sla
    t – уже прошедшее время по заявке

    Да, эта схема похожа на ту, что “смотри на срочность, получишь приоритет”. Вроде бы и ITIL -овскую схему сохраняем, вроде бы и удобно?

    • Роман Журавлёв

      Коллега, а как вы определяете Urgency и Impact? (вопрос не о процедуре, а о сути понятий)
      А ещё – в чем измеряются T и t ? И что такое “срок для события по SLA”? Кто с кем подписал SLA про такой срок?
      Поскольку значение t постоянно меняется, значение приоритета – тоже?

      В общем, расскажите подробности.
      Спасибо!

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

      В сентябре я проводил webinar на тему определения приоритетов и сроков инцидентов. Мне кажется, там есть ответ на Ваш вопрос. Слайдкаст можно посмотреть здесь: http://www.slideshare.net/Cleverics/ss-9304501

      • Isenshtill

        большое спасибо, я посмотрю на новогодних праздниках.

  • Isenshtill

    Роман,

    подробности таковы:
    Urgency – это ITIL-овская срочность – в зависимости от того, блокирует ли инцидент работу пользователя, и нету достойного обходного решения. Этот параметр может оценивать и сам пользователь. Если это change – он тоже может быть срочным или нет – внеплановый апгрейд влияющий на бизнес, или штатное изменение CI по запросу.

    Impact – по количеству пользователей, на кого влияет данная заявка. (1, группа, все ). Сюда же можно включить категорию VIP заявок.

    T – это есть наша срочность, исходя из срока выполнения заявки – срок из sla, как руководитель бизнес-подразделения подписал с IT отделом. Например – массовые и виповые – в течение часа, обычные – в течение дня.

    t – то время, которое уже прошло.

    Та формула, которую я написал – она абстрактная, основанная на двух утверждениях (моих лично-субъективных).
    1) Приоритет должен учитывать срок выполнения заявки, чтобы тех.специалист не производил лишних действий в уме по выбору заявок и их самостоятельную приоритезацию (или производил, но минимум). Приоритет должен быть инструментом удобства и наглядности.
    2) С течением времени приоритет должен изменяться. Логично, что заявки с одинаковым приоритетом должны обрабатываться в соответствии с их поступлением. Отсюда вывод, что две заявки, поданные разное время с одинаковым приоритетом, через некоторое время будут иметь разный приоритет.

    Так что, если быть математически верным, то, возможно, приоритет стоит вычислять следующим образом.

    urgency*impact мы берём число из матрицы приоритетов.
    Пусть это будет:
    1 2 3
    2 3 4
    3 4 5
    Возьмём для примера из этой матрицы центральное значение, когда impact=urgency=2, значит impact*urgecny=3.

    так же, для примера возьмём значения T из sla – 3 дня.
    Ну, и , соответственно t – тоже число прошедшего времени в днях. Пусть это будет 1 день.
    T и t мы будем исчислять в одинаковых единицах, можно в днях, можно в часах.

    итого, математика такова:
    Priority=imp*Urg/(T-t)=3/(3-1)=1.5

    Приоритет в итоге – просто число, по которому мы можем ранжировать заявки.

    Соответственно, при подходе времени и\или t>T – эскалация.

    Конечно, в итоге, сотруднику придётся выбирать – между например долго висящей не срочной заявкой, и срочной( в смысле сроков) заявкой только что поступившей. Т.е. всеравно мы не уйдём от “приоритета в приоритете”, и не уйдём никогда, потому что в всегда выбор будет осуществляться на основе тех человеко-аналитических величин, которые машина учесть не может – например, приблизительное время, за которое сотрудник сможет выполнить заявку.

  • Анатолий

    Идея понравилась, а

    Надо ли менять приоритет? Ведь в заявке есть срок выполнения. Срок подходит, это видят ответственные.

    2 заявки

    А – высокий приоритет – 3 часа

    Б – низкий приоритет – 24 часа.

    Через 20 часов не меняя приоритета, она и так будет светиться у ответственного, как ожидающая решения, иначе будет нарушение срока, эскалация и т.д.. 

    Изменяемый автоматически приоритет, даст в итоговой статистике близкую к 100% высоких приоритетов. Если же необходимо делать анализ по проблемам в сопровождаемой системе, то отделить мелкие ошибки самих пользователей, от сбоев системы будет затруднительно.

    Опять же это может быть одним их элементов KPI, или же крутые решают высокие приоритеты, а студенты низкие и ан них происходит обучение.

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

     

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

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

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