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

Взаимодействие 1-й и 2-й линий поддержки в системе автоматизации

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

В очередной раз с несколькими заказчиками обсуждали способы организации взаимодействия первой и второй линий поддержки в системе автоматизации процесса управления инцидентами. В моей голове существует два принципиально различных способа:

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

Согласен, у каждого способа есть свои плюсы и минусы. Вместе с тем, моя практика показывает, что у второго способа плюсов больше (в том числе в случае сложных «запросов», требующих работы нескольких групп, типа запросов на организацию нового рабочего места). Скажу даже более категорично: если система автоматизации обеспечивает должный контроль переназначения обращений / инцидентов между группами, я всегда начинаю со второго способа, пока какая-то «суровая» специфика заказчика не убедит меня в обратном.

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

Коллеги, поделитесь мыслями. Может быть, кто-то убедит меня, что первый способ обладает серьезными преимуществами, которых я до сих пор не замечал? Что говорит Ваша практика?
 

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

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

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

  • old fuddy-duddy

    На первый взгляд мне 2-й вариант тоже кажется более правильным, или более соответствующим логике и идеям ITIL. Однако, распространенность 1-го варианта, возможно, связана не с «тяжелым наследием» HPOVSD, а со спецификой конкретной организации. Так, например, при наличии достаточно компетентных специалистов на первой линии поддержки и при эффективном механизме мотивации по заданиям, 1-й вариант работает не хуже 2-го, будучи при этом «компактнее».

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

      По поводу “компактности” не осознал. Приведу несколько примеров, когда вариант 1 добавляет “минусов” (это список “наугад”, не полная систематизированная выборка, но она показательна):

      1. увеличение нагрузки на Service Desk, причем часто (не всегда) без каких-либо значимых “выгод” взамен;
      2. сложности с контролем просрочки обращений / инцидентов (поскольку все задания могут быть выполнены в срок, а обращение / инцидент – просрочено), да и сам расчет срока задания по обращению вызывает вопрос;
      3. сложности с пересмотром срока обращений / инцидентов (поскольку профильные специалисты не имеют возможности редактировать обращение / инцидент, а только назначенное им задание), а не по всем видам обращений можно установить фиксированный нормативный срок;
      4. дополнительные задержки при переназначении обращений / инцидентов (поскольку задания обычно не переназначаются, а возвращаются инициатору, в данном случае SD, который затем должен делать новое задание на другую группу);
      5. размывание ответственности за восстановление услуги (каждый просто выполняет свое задание, только SD работает с обращением / инцидентом, но с него спрос невелик, поскольку он во многих случаях может лишь выполнять контрольные функции, но не восстановить услугу самостоятельно);
      6. труднее для конечного исполнителя собрать комментарии коллег, участвовавших в обработке обращения / инцидента до него и собравших возможно важные сведения (например, по диагностике инцидента).

      Еще раз, это просто примеры – не исчерпывающий список. Поэтому вопрос: что такое “будучи при этом «компактнее»”? В чем конкретно копактность 1-го варианта?

      • old fuddy-duddy

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

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

          “соответственно короче (по этапам) путь от приема обращения до выполнения задания”

          “По этапам” – может быть (только на что это влияет?). По времени обработки – сомнительно. По трудозатратам – еще более сомнительно.

    • Начальник службы Service Desk

      А Вы давно читали Service Operation?

      Note: Incident Ownership remains with the Service Desk! Regardless of where an incident is referred to during its life, ownership of the incident remains with the Service Desk at all times. The Service Desk remains responsible for tracking progress, keeping users informed and ultimately for Incident Closure.

      Как это коррелируется с Вашим высказыванием, что 2-й вариант “более соотвествует логике и идеям ITIL” )))?

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

        О, отличный вопрос. Честно, жаль, что задан не мне. Подождем ответ?

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

          И правда, вопрос интересный. Инциденты ведь разные бывают – о каких-то мы узнаём от пользователей, а какие-то происходят в инфраструктуре, да пользователи о них не знают. Тем более – Service Desk 🙂

          • Начальник службы Service Desk

            Извините, а к чему вы об Incident “Source” ?

            Знание Service Desk об инфраструктурных инцидентах можно достичь путем совмещения функции мониторинга и службы Service Desk в одном подразделении.

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

              Я не об источнике, а о видах инцидентов. Но здесь мы друг друга понимаем.

              Совмещение мониторинга и службы Service Desk, в моём понимании, всё же частный случай. В более общем случае Service Desk может не знать об инфраструктурных инцидентах (что не случайность, а политика процесса). В этом случае, более общем, владение такими инцидентами также не находится на Service Desk.

              (кстати, тов. начальник, не хотите представиться? с кем имеем честь? 🙂 )

      • Георгий

        я бы, с вашего позволения дополнил 🙂
        Этот вопрос относится к “классическим”, то есть к тем, которые возникают в более 95% проектов по внедрению Inc Mngmt 🙂
        Так вот, если следовать четко заповедям ITILv3, то там указано что

        что инцидент эскалируется на 2 или сразу на 3 линию (как технически происходит эскалация не прояснено)
        Потом есть добаление, которое отлично привел коллега, про “Владение” инцидентом
        и в конце есть активность “Закрытие” перед которой инцидент “возвращается” на servicedesk для закрытия, а ServiceDesk закрывает его

        То есть наиболее близкий к ITIL вариант автоматизации (с моей точки понимания книжки) это передача инцидента на 2 или 3 линию, потом возврат на ServiceDesk и перевод в “Решен” (или “waiting for close accept” для олдфагов 🙂 ) уже сотрудниками ServiceDesk

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

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

          Гоша, жму руку. Люди доброй воли должны держаться вместе 🙂

          Что касается цитаты про владение инцидентом, то:

          1. книжки ITIL используют слово owner не менее вольно и разнообразно, чем слово process, поэтому каждый раз надо догадываться о чем идет речь (в частности, я бы сказал, что владение инцидентом, пришедшим от пользователя, это удел самого пользователя, например, только он должен иметь возможность его отменить, закрыть, тем или иным техническим способом, он имеет право позвонить и потребовать отчет о ходе обработки и так далее);

          2. контроль обработки инцидента может быть организован и без назначения инцидента на SD (и это правильно, т.к. четко фиксирует ответственность за решение инцидента на группе профильных специалистов), так что вариант 2 – никак не противоречит ITIL;

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

  • masya

    7 лет работаю по второму принципу – проблем нет:)

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

      1. Выбирали между первым и вторым? Или просто стали работать по второму принципу и проблем не появилось?
      2. Аутальна ли для Вас задача учета трудозатрат при устранении инцидентов / обработке запросов? Если да, как решаете, если одно обращение / инцидент последовательно передается между 2-3 группами (например, в ходе диагностики инцидент с ПО сначала назначили на группу сопровождения ПО, затем, разобравшись, перенаправили в группу поддержки десктопов)?

      • masya

        сразу работали по второму/ Наверное как привыкли работать, на все были процедуры
        второй вопрос не совсем понятен. Если я его правильно понял…
        Думаю все должно быть оговорено в SLA и SLO. Например, если заявка не решается в течении допустим 4х часов, то руководителю автоматом уходит письмо и он подключается и разбирается почему проблема не решается. Если начинается “футбол” между группами, то тут думаю надо работать с самими группами (т.е. с людьми)

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

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

          И еще, скажите, пжл, какой софт использован для автоматизации? Если уже 7 лет работаете, то наверно HPOVSD?

          • masya

            А если так, то вопрос у нас не стоит в учете непосредственно самих трудозатрат. У нас учитывается уже окончательныйй результат – “заявка выполнена”.
            Был HPOVSD, сейчас осваиваем HPSM 9.20.

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

      Многие десетилетиями работают не зная что такое ITIl или ITSM, и тоже не имеют проблем 🙂

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

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

    Навскидку я вижу два сценария, когда этот вариант может быть оправдан:
    1. вторая линия – на самом деле не вторая, а 1.1 (в рамках службы поддержки). Тогда ее сотрудники могут рассматриваться как ресурс операторов, и последние могут разумно назначать им задания.

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

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

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

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

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

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

      Т.е. это ответ на вопрос почему 1-й вариант _иногда_ может быть правильным, а мой вопрос, почему 1-й вариант так часто считается правильным, в то время, как мне кажется, что это скорее исключение из правил. А?

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

        Мне такие варианты попадались редко, но осмелюсь предположить, что в некоторых случаях дело все же в логике систем автоматизации, которые использовались, и это не только HP OV SD.

      • old fuddy-duddy

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

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

          “1-й вариант, как мне кажется, присущ малым и средним организациям”.

          1. Почему? На них перечисленные мной 6 пунктов выше не распространяются? Или они настолько малы, что там нет потребности в заданиях, поскольку все работы по обращениям / инцидентам выполняет один человек? Если да, то это не очень интересно, так сказать “вырожденный случай”.
          2. Прошу пояснить. Вы считаете, что малым и средним организациям _лучше_ использовать 1-й вариант (если да, почему) или что в малых и средних организациях 1-й вариант по каким-то причинам чаще встречается (опять же любопытно Ваше предположение о причинах)?

  • Андрей Радосельский

    По моему мнению это может быть связано с правилами контроля процесса, а именно с метрикой “Крайний срок” и ограничениями Систем в учете времени “владения обращением\инцидентом\заявкой”.

    Если в организации основной учет/контроль времени “владения заявкой” осуществляется не целиком (SLA/SLM), а на уровне отдельных отделов/”назначенных лиц” (например, в каждом отделе заявка должна болтаться не назначенной не более 1 часа, и при возврате она возвращается на 1-ю линию, Отдел задание отработал в срок – до свиданья с претенциями), то в существующих Системах (HP SM, BMC Remedy) учет такой деятельности по модели 2 – затруднителен, надо писать дополнение “Журнал владения”.

    2-я причина, как выше уже сказали, совмещение в одном объекте системы автоматизации 2-х процессов: Инциденты и Сервисные запросы. Если их разделить и преодолеть подход, который я описал выше, то вариант 1 – однозначно (IMHO) mast be.

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

      “2-я причина, как выше уже сказали, совмещение в одном объекте системы автоматизации 2-х процессов: Инциденты и Сервисные запросы. Если их разделить и преодолеть подход, который я описал выше, то вариант 1 — однозначно (IMHO) mast be.”

      Андрей, объясните вывод, пожалуйста. Почему 1-й вариант однозначно must be? Почему не второй?

      • Андрей Радосельский

        ошибка вышла -)
        1-й вариант для сервисных запросов и изменений
        2-й для инцидентов

  • Андрей Радосельский

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

    Например для “Организации раб места” (куда же без него -))) Одновременно стартуют, как минимум:
    – телефония
    – сетевая розетка
    – ПК
    – акаунты на ресурсах

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

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

      Т.е. по-моему приведенный Вами пример совсем не обязательно означает использование 1-го варианта. И у меня есть много подобных реализаций на практике.

      • Андрей Радосельский

        “отвечает за общую координацию работ?” – одна точка контакта для пользователя и один телефон на ответ “А чо, когда будет то?”. А у вас этих точек N-штук. Бардак, разброд, и шатание…

        “И у меня есть много подобных реализаций на практике” – да разве я ж против, я и сам такие реализации делал – мы ж о IMHO говорим -)

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

          “одна точка контакта для пользователя и один телефон на ответ «А чо, когда будет то?». А у вас этих точек N-штук. Бардак, разброд, и шатание… ”

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

          • Андрей Радосельский

            Первая линия – Сервис деск
            Ответственость за организацию работ – Сервис деск, менеджеры и координаторы процессов – Сервис деск.

            Перекресное распределение точек ответствености между отделами примодит к грызне или взаимной поруке.

            that’s all/

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

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

              Все-таки Service Desk – просто инструмент коммуникации между ИТ и пользователями. То, что на эту службу часто ложатся еще и все управленческие функции в ITSM, есть признак неоптимального управления, а не многофункциональности SD. Хвост виляет собакой.

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

                Ром, +1. Второй абзац – в точку.

              • Андрей Радосельский

                Наверно вы правы, академическим подходом на земле и не пахнет. Но я всегда вспоминаю в таком случае историю с протоколами передачи данных OSI и TCP/IP.

                Я всегда заказчику предлагаю вынести менеджеров процессов в отдельное подразделение, типа “Процессный офис”.

              • Dmitriy

                Насчет второго пункта – готов подписаться под каждым словом. А есть ли видение более правильного подхода?

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

              Андрей, я, честно говоря, немного потерял нить. Почему за все отвечает сервис деск? Почему разделение точки контакта и точки ответственности за обработку ряда обращений приводит к грызне? Почему аналогичная схема не приводит к грызне при обработке инцидентов? Зачем нужны дополнительные сложности в виде разных схем взаимодействия между 1-й и 2-й линиями при обработке инцидентов и сервисных запросов?

              • Андрей Радосельский

                О, я также подумал, про нить.
                Мы начали с того, что я сказал – задания надо генерировать для сервисных запросов, а не для инцидентов. Про то что SD является точкой ответствености – я не говорил, и сам так не думаю.

                Но то что точка ответствености должна быть единой и внешней по отношению к исполнителям работ в случае комплексных работ – ну я так считаю -)

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

    Кстати, Дим, возможно, причина широкого распространения твоего “первого варианта” – именно в этом: за неимением других кандидатов на роль координаторов деятельности максимум контролей сосредотачивается в руках или под руками SD. Кто-то же должен их держать…
    Постепенно это становится привычным и естественным решением, и другие просто не рассматриваются. Если такую привычку обретает консультант, он начинает тиражировать это решение из проекта в проект.

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

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

    • Dmitriy

      И это неправильно.. На сервис-деск таким образом возлагаются почетные, но совершенно несвойственные этой функции функции, уж простите за тавтологию. 🙂

  • Александр

    Самая главная причина – при эскалации теряется контакт с пользователем. Заявка остается на первой линии (читай “на земле”), и из нее же идет координация работ.

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

      “Самая главная причина — при эскалации теряется контакт с пользователем”

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

      • Александр

        Очень просто – зачастую именно только они могут дойти до пользователя “ногами”.

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

          Александр, сплошные если:

          1. если организация не является территориально распределенной (с централизованным сервис-деском);
          2. если у сотрудников сервис-деск хватит компетенции задать правильный вопрос (много Вы знаете примеров, когда у сервис-деск хватает знаний разобраться с вопросом по прикладному ПО типа “не формируется заказ”, “не проходит проводка”, “не закрывается договор” и так далее);
          3. если у сотрудников сервис-деск достаточно ресурсов “доходить до пользователя ногами”, не снижая доступность единой точки контакта (что по моей практике вообще редкость, из-за чего сотрудники сервис-деск почти никогда не ходят ногами, а привлекают в случае такой необходимости других специалистов).

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

          • Александр

            1. Ну в случае не территориально-распределенной – а много их таких осталось, чтобы все в одном месте?
            2. А для этого у них есть карты-вопросники. Тут вопрос организации процесса.
            3. Тут я конечно немного утрирую. скорее имелось ввиду то что выше было названо линией поддержки 1.1.

            • Александр

              Просто как показывает практика Help Desk и Service Desk все более и более сливаются.
              Если под второй линией имелся ввиду Help Desk в лице “эникейщиков широкого профиля” то я пожалуй заберу свои слова обратно.

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

              1. Да. А куда они должны были деться?
              2. В ходе первичного контакта это помогает. В ходе дальнейшего решения после передачи вопроса предметникам – очень сомневаюсь.
              3. Я так и подумал 🙂

    • Александр

      Добавлю, что это не касается тех заявок исполняемых целиком в рамках одной группы. Тут дело вот еще в чем. ITSM это в первую очередь процессный подход, это главенство процесса над структурой. Но не вся работа выполнется в рамках процессов. Есть много чего, что приходится делать отечественным айтишникам. Поэтому, никто не спешит залзить в матричную структуру, поэтому самый дешевый способ найти координаторов – это посадить их в районе SD – им виднее..

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

        “поэтому самый дешевый способ найти координаторов — это посадить их в районе SD — им виднее…”

        Думаете? Не знаю… По-моему, это путь к конфликту. В организациях, где SD только внедряется, он какое-то время воспринимается как “лишнее звено” и конечными пользователями, и второй линией. И мы обычно стараемся даже контрольные функции максимально ассоциировать не с SD, а с системой автоматизации, чтобы не усугблять конфликт. А в предлагаемом Вами решении SD и организатор, и контролер. Причем он должен организовывать и контролировать работу людей более выской квалификации. Как же это спасает отечественных айтишников от матрицы?

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

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

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

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

    1. копипаст (зачастую бездумный) решения, ориентированного на компанию, где SD – единственный отдел, где есть шанс навести порядок, и только на него и можно “вешать” хоть какие-то контрольные функции;
    2. ограничения систем автоматизации, не обладающих должным контролем и учетом переназначений. А в нынешнее время скорее – нежелание настраивать системы автоматизации, поскольку многие современные продукты если и не поддерживают это штатно, то позволяют такой функционал реализовать. Как говорит одна моя знакомая: “Если айтишник не знает как это сделать, он скажет – это невозможно”.

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

      Дмитрий, надеюсь вы ещё не закрыли дискусию, подведя итог. А то я давненько в гостях у вас не бывал, а вы тут столько понаписали… А мне тоже хочется свой след в истории оставить. 🙂

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

      Во-вторых, я сторонник некоего третьего промежуточного варианта. ОБРАЩЕНИЕ назначается на исполнителей (группу или персонально это другой вопрос), но любые свои действия по этому обращению исполнитель должен описать ЗАДАНИЕМ. ЗАДАНИЕ исполнитель может назначать на себя, либо на другого исполнителя. Изменять ОБРАЩЕНИЕ исполнители не могут (возможно могут изменять только отдельные свойства, это уже требует конкретики).

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

        Павел, я рад что Вы здесь и открою для Вас все заново 🙂 Мне не хватало Вашей систематизации в этой дискуссии.

        Что касается предложенного Вами подхода, требуется пояснение. Не понимаю зачем исполнителю свою работу по обращению отражать в системе учета как задания, назначенные на себя же (как частный случай), какую задачу это решает? Это способ учитывать шаги (трудозатраты, результаты, …) различных сотрудников по обращению в условиях функциональных ограничений HPOVSD? Или это не связано с ограничениями инструмента?

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

          Функциональных ограничений это не касается.
          Чтобы попытаться осветить свою идею начну немного издалека.
          Всякая система учёта это модель реальной жизни. Что делает в реальной жизни всякий работник? Как и следует из названия, работает, т.е. выполняет работы. Потребность в выполнении работ может быть вызвана различными причинами: инцидент, запрос на обслуживание, участие в проекте, иное распоряжение руководства и тд. Таким образом, если нам интересно понимать загруженность своих работников (цели для этого могут быть разные, не стану сейчас все их перечислять) то необходимо организовать учёт всех работ. Этот учёт лучше организовать в виде отдельных объектов, называемых в этой ветке Заданиями. В этом случае чтобы оценить загруженность работника достаточно посмотреть на количество назначенных ему Заданий, а не Инцидентов, Изменений, Проектов, Заданий и пр. К тому же возможны ситуации, что работник, в рамках решения какого-то Обращения, устраняет некий Инцидент или несколько (а реально работа выполняется одна), в итоге оценка его загруженности окажется в два раза больше чем на самом деле.
          Кроме этого ещё ряд преимуществ этой схемы:
          – однообразие, правила отражения действий одинаковые для всех случаев (с меньшим количеством ЕСЛИ, ТО…);
          – адекватный учёт параллельных и последовательных работ, однозначно видно кто, какие и сколько работ выполнял, работы не скрываются внутри других объектов;
          – масштабируемость, если у нас сейчас организован учёт только Обращений, то с вводом учёта ещё и Изменений, просто добавятся работы по изменениям, но не будет необходимости осваивать правила описания Изменений и пр. (хотя здесь есть другой момент, я бы рекомендовал начинать вообще с учёта работ, а потом уже добавлять Инциденты, Обращения, Изменения и др.);
          – возможность разделять «объект» Обращения и «объект» работ, пользователь жаловался на медленную работу электронной почты, а работы проводились по переустановке антивируса на его ПК и изменению настроек сети (здесь конечно можно дискутировать на тему «жаловался ли пользователь на программу или сервис», «являются ли эти работы изменением или инцидентом» и т.д., но это за рамками этого топика).

          Вот как-то так, не уверен достаточно ли ясно изложил. Если сумбурно, то придётся вам, коллеги, подождать пока я напишу статью на эту тему с картинками и таблицами. 🙂

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

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

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

            Есть и дугие вопросы. Например, как будут определяться сроки заданий в составе инцидентов? И не получится ли так, что все ИТ-шники будут в шоколаде, т.к. задания выполняются в срок (ведь ИТ-шников согласно идее для единообразия оценивают именно по заданиям), при том, что по обращениям будет (не)приличная просрочка?

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

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

            “придётся вам, коллеги, подождать пока я напишу статью на эту тему с картинками и таблицами.”

            А есть такие планы?

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

    Отвечаю по пунктам:
    1. “А есть такие планы?” – Будут, по многочисленным просьбам трудящихся или при наличии настроения и времени одновременно. 🙂

    2. “в составе инцидента нам нескольких заданий не нужно” – А если нужно? А если сначала думали, что не нужно, а потом решили, что нужно? Для каждого случая надо применять свою схему, считаю что лучше безобразно, но однообразно. Чем нагружать работника размышлениями “по какой же схеме мне сейчас идти”.

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

    4. “зачем назначать инцидент мне и заставлять меня самостоятельно создавать себе еще и задание?” – предполагается, что 1-я линия не компетентна принять 100% верное решение, о том какие именно работы нужны, вы ли их будете делать, решите ли вы его сами или будете привлекать кого-то ещё. Можно пойти другим путём назначать на необходимого (по мнению 1-й линии) исполнителя или группу задание “решить обращение”, при этом исполнителям дать права на создание связанных с обращением заданий, если ему вдруг понадобится помощь. Такой вариант удобен, кстати, при отработке стандартных задач, когда 1-я линия раскидываем заранее известный набор заданий и контролирует их выполнение.

    5. “как будут определяться сроки заданий в составе инцидентов” – сложный вопрос, отвечу на него другим вопросом, “А как определять допустимые сроки в которые заявка может быть переназначена на другого специалиста или группу? А как быть при привлечение к заявке нескольких исполнителей?”.
    У меня есть следующие решения:
    Простейшее – карйний срок задания ставится равным крайнему сроку заявки.
    Продвинутый – задания привязываются к OLA и сроки берутся оттуда (вот этого, кстати в HPOVSD нет, насколько помню).

    6. “не получится ли так, что все ИТ-шники будут в шоколаде” – Может. Надо не забывать про баланс, все оценки должны быть сбалансированными. Надо оценивать не только его трудозатраты, но и сложность, и количество, и своевременность и т.д.
    Возможна же и другая ситуация: заявка назначается на работника 1, работник 1 волынит её, а когда осталось 30% до крайнего срока, перекидывает её следующему по цепочке работнику 2, трудоёмкость работ работника 2 больше чем 30% и он даже гипотетически не успевает выполнить заявку, в итоге работник 1 в шоколаде (хотя волынку тянул), работник 2 лишён премии (хотя работал в поте лица).
    Опять же нужно отличать оценку текущей загруженности работника (сколько у него в данный момент работы) от оценки его достижений (как хорошо он работал в течение месяца, квартала, года).

    7. “можно просто вести единый учет трудозатрат, которые могут указываться в составе и заданий, и обращений, и инцидентов, и других объектов (если есть)” – Но Дмитрий, этоже вопрос конкретных реализаций. Трудозатраты могут быть внутренним подобъектом или внешним объектом, сути-то это не меняет. Если нам важно учитывать только трудозатраты, то можно в том же HPOVSD придумать обходные решения: банально писать в какое-то поле через запятую цифры, а потом каким-нибудь Excel всё это суммировать. Но если мы хотим понять структуру трудозатрат, оценить текущую загруженность специалистов, оценить трудозатраты связанные с несколькими задачами одновременно (обращение и инцидент, например), то этого недостаточно.

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

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

      “считаю что лучше безобразно, но однообразно”. Тут спорить не могу – это личное дело каждого 🙂

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

      Крайне трудно реализуемо на практике. Я даже вопросы не буду задавать про способ оценки сложности, про то, как оценивать своевременность по заданиям, сроки которых устанавливают исполнители, и так далее. Это тупик. Надо упрощать. Работать помогают простые схемы, сложные – помогают запутываться и подменять суть работы ее формой.

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

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

        Тогда у меня один вопрос, Дмитрий: Что является мерой простоты? Как отличить простое от сложного?

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

          Я когда-то занимался этой темой, когда учился в ВУЗе. Тогда же читал известную книг Ильи Пригожина “Познание сложного” (ISBN 5-354-00273-7). “Большой” ответ на Ваш вопрос – там.

          Сложным здесь я считаю несколько моментов.

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

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

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

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

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

            Таким образом, я считаю, что в условиях, когда вы организуете управление инцидентами, подавляющая часть из которых решается одним исполнителем. Учёт других работ, планирование и оптимизация трудовых ресурсов, типизация решений не ведёться и в ближайшее время не планируется, то оптимальнее использовать вариант 2, предложенный вами.
            В противном случае вариант предложенный мной.

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

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

              Я не уследил за логикой – как это учет других работ, планирование ресурсов и типизация решений – все в одночасье вычеркнута из “второго варианта”? Павел, повторюсь, “все (подчеркиваю, _все_) поставленные Вами задачи могут быть решены во «втором варианте»”. Я нигде и не говорил, что оценивать надо только по просрочке. Есть разные подходы. Один из моих клиентов, например, учитывает именно трудозатраты, при этом трудозатраты по просроченным инцидентам снижаются пропорционально размеру просрочки. И я уже не помню ни одного клиента, которого единственная метрика по просрочке устроила в качестве основы для системы мотивации персонала.

              Скажу больше. Даже если я вообще забуду про задания и буду учитывать только инциденты, я смогу адекватно учитывать трудозатраты. В том числе с учетом ситуаций, когда над одним инцидентом последовательно трудилось несколько человек. В том числе поименно, по периодам времени, по типам трудозатрат, по группам, по начальникам и т.д. Зуб даю.

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

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

                “повторюсь, «все (подчеркиваю, _все_) поставленные Вами задачи могут быть решены во «втором варианте»»”

                Дмитрий, чтобы не быть голословным расскажите как вы видите себе такую реализацию. Есть у меня подозрение, что мы с вами говорим об одном и том же, но по разному это понимаем.
                Давайте для примера рассмотрим две ситуации:
                1. Есть заявка, назначена на Исполнителя_1. Исполнитель_1 понимает, что ему нужна помощь двух его коллег Исполнитель_2 и Исполнитель_3, которые должны работать паралельно с ним.
                Задача учесть, сколько каждый из исполнителей отработал, и какого рода работу выполнял (предположим, что у нас есть классификатор работ).
                2. Исполнители работают над решением заявок, выполняют некие профилактические работы (по графику) и участвуют в некой внутренней проектной деятельности. Задача необходимо иметь возможность оценить, как в текущий момент загружен каждый исполнитель, какая нагрузка на него планируется завтра, через неделю и т.д.

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

                  Павел, не сочтите за рекламу, можно я Вам отвечу ссылками? Там просто уже все это расписано, причем с картинками.

                  1. http://www.cleverics.ru/ru/services/omnitracker/233-chained-workorders
                  2. http://www.cleverics.ru/ru/services/omnitracker/244-workload-accounting

                  Ваш пункт 2 реализуется конечно через задания. В том числе возможно через автоматически формируемые задания на день.

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

                    Дмитрий, но предложенные вами статьи фактически и описывают тот вариант, что предлагаю я, простите уж мою нескромность. 
                    Где-то выше я говорил, что под заданием я понимаю некий отдельный объект, описывающий отдельную работу (правильней его называть даже не задание, а именно работа), не важно как он называется. В вашем примере 2, фактически описание работы разбито на два объекта «Трудозатраты» и «Задание», «Трудозатраты» должны быть созданы в любом случае, «Задание» опционально. В чём разница, если бы исполнитель всегда создавал «Задание»? В этом случае, как минимум, в схеме меньше элементов, а потому и меньше вероятность каких-либо ошибок. С другой стороны не раскрыт вопрос «как связывать трудозатраты с несколькими объектами», например, если по данному обращению были решены несколько инцидентов, а если были какие-то работы связанные не только с решением инцидента, но тоже относятся к данному обращению?
                    А по ссылке 1 пример даже больше похоже на ваш вариант 1.
                    И самое главное нет ответов на вопросы, которые вы задавали мне, в частности, «как будут определяться сроки заданий в составе инцидентов?».

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

                      1. Ну отлично, договорились 🙂
                      2. “как будут определяться сроки заданий в составе инцидентов?”. Павел, тут видимо есть недопонимание. Я как раз и писал, что такие правила в общем виде определить невозможно. Но если создавать задания в случае комплексных работ (несколько заданий в составе одного обращения или инцидента), то эти работы как правило стандартны и сроки можно определить шаблонами. А вот если создавать задание на каждый инцидент, даже если он требует работы одного человека, то срок у таких заданий каждый раз придется указывать вручную (именно потому, что копировать в задание срок из инцидента я считаю неправильным). В моем варианте такой проблемы просто нет (или по крайней мере нет в большинстве случаев) – мне не надо уметь ее решать.

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

                      “С другой стороны не раскрыт вопрос «как связывать трудозатраты с несколькими объектами», например, если по данному обращению были решены несколько инцидентов, а если были какие-то работы связанные не только с решением инцидента, но тоже относятся к данному обращению?”

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

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

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

                Насчёт лишних трудозатрат я уже писал выше, если 3-5 кликов и считать лишними трудозатратми, то всё это решается на уровне автоматизированной системы, как вы говорите, единоразово на уровне проекта.
                Ну а от предположений нам никуда не деться ни в вашем варианте, ни в моём.
                А вот что касается анализа, то тут я с вами не согласен, если вы конечно предполагаете ограничить анализ N-ным количеством отчётов, то, спору нет, можно всё решить на этапе проектировани и автоматизации. Если же нужна гибкость и возможность манипулировать данными (в лучшем смысле этого слова), то вам скорее, всего придёться пристроить ещё и систему бизнес-аналитики.

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

    Дмитрий, к сожалению мы с вами достигли предельной глубины вложенности, не подумайте плохого, комментариев. 🙂
    Придёться ответить новой веткой, что несколько конечно запутает обсуждение, но я думаю не долго ему осталось.

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

    Давайте посмотрим на ситуацию внимательней, возможные ситуации:
    1. Заявка исполняется одним человеком.
    Вы считаете заявку одновременно и заданием, с крайним сроком вопросов нет.
    Я создаю Задание, крайний срок Задания ставлю автоматом равным крайнему сроку заявки.
    Никакого противоречия или дополнительных неопределённостей.
    2. Заявка решается коллективно, но по шаблону.
    Вы создаёте Задания по шаблону и по шаблону же ставите крайний срок.
    Я создаю Задания по шаблону и по шаблону же ставлю крайний срок.
    Никакой разницы.
    3. Заявка решается коллективно, но она не типовая.
    Вы создаёте к Заявке Задания, но крайний срок не заполняется, их инициатор должен сам принять решение какой срок ставить.
    Я создаю к Заявкае Задания, и ставлю крайний срок каждого задания равный крайнему сроку Заявки, а инициатор может его при желании изменить.
    В итоге, что Вам, что мне придёться принимать решение только в этой единственной ситуации.
    Но в моём случае трудозатраты будут меньше, поскольку инициатор может оставить срок задания по умолчанию, а у Вас обязательно должен заполнить. 🙂

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

      Павел, ну не в этом дело 🙂 Заполнить срок и я могу автоматом. Вопрос не в том можно ли, а в том правильно ли.

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

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

      Но более важный вопрос здесь – не трудозатраты, а контроль. Если я буду контролировать просрочку, я буду это делать по нормативам в SLA. Если Вы будете контролировать просрочку, то:

      1. по обращениям / инцидентам ее контролировать нельзя (т.к. с момента моего завершения работы над заданием еще пройдет какое-то время пока обращение / инцидент кем-то будут отмечены как решенные);
      2. по заданиям ее контролировать не получится, т.к. сроки можно менять вручную, жестких ограничений на “больше или меньше срока по обращению / инциденту” поставить не получится (см. выше), а значит я себе поставлю любой срок.

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

      Устал писать…. 🙂

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

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

        Так не честно, Дмитрий, сами Вы, значит, аппелируете к бескрайним возможностям автоматизации, а мне в таком праве отказываете. Я уже писал выше, что проблему “кто закрывать будет” вполне реально решить в средстве автоматизации и даже в HPOVSD. 🙂

        Со сроками вопрос что с одной стороны, что с другой скользкий. Ставить автоматом, не будут менять (правда можно попытаться мотивировать быть внимательней). Заставлять заполнять самим, будут ставить нереальные заниженные сроки (поставлю час, чтобы напугать, глядишь за два сделают, а то поставлю два, будут делать 4…).

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

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

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

          В остальном – в целом соласен 🙂

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

        Я тут у вас в глазу соринку углядел. 🙂
        относительно трудозатрат при следующей схеме:
        Есть 10 заявок, например, не работает интернет. Инцидент на всё это один – модем забарахлил. Устранили двумя Задачами линию проверили, модем перезапустили, на каждую по полчаса. Имем связь 10 Заявок к Инциденту, а он к двум Задачам.
        Трудоёмкость Инцидента складывается из Задач и равна час. Трудоёмкость каждой Заявки наследуется из Инцидента и тоже равна час. В итоге трудоёмкость всех заявок по услуге 10 часов, а работали всего час…

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

          Нет, Павел, Вам показалось (про соринку) 🙂

          Связи между инцидентами и обращениями – many to many, поэтому по ним трудозатраты не суммируются. Суммируются по заданиям в составе одного головного объекта – обращения или инцидента (а также других). Поэтому трудозатраты останутся 1 час.

          Более того, отчеты по трудозтратам формируются не по таблице инцидентов, а по таблице записей о трудозатратах. А там дублирования никак нет.

  • Кротов Алексей

    Хотелось бы повторно поднять этот вопрос. Сейчас в процессе проект по внедрению упр-я инцидентами. Необходимо определить, на ком будет оставаться инцидент/заявка. Предложение интегратора – оставлять его на 1ой линии/диспетчере, к-рый будут выполнять контрольные ф-ции и создавать задачи для 2ой линии. Аргументация – нужен кто-то, кто будет контролировать соблюдение SLA; если, что, ты потрясет спец-та 2ой линии, его рук-теля или вообще эксалирует на сервис-менеджера. При этом это требует, чтобы сотрудник, к-рый занимается приемом и классификацией заявок был достаточно продвинутым по БП компании, чтобы менять приоритеты, контролировать сроки выполнения сотрудниками 2ых линий (т.к. они разделены по функциональным группам).

    Меня это смущает, т.к. по факту сейчас у нас нет и не планируется выделение отдельной вакансии на прием/классификацию заявок; персонал 1ой линии знаком больше с десктопными задачами (windows, печать etc.). Они, как отмечалось в обсуждении ранее, недостаточно квалифицированы, чтобы понимать, где их специализированные отделы "нагреют".  При этом именно они будут ответственны перед заказчиком за соблюдение SLA.

    Есть здравое зерно в предложении – а на ком тогда должна быть ответственность за заявку, если она требует участия нес-ких функциональных групп?

    • Nargiza Suleymanova

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

      • Кротов Алексей

        Процесс подразумевается единый, т.е. вне зависимости от того, будет ли в обращении 1 задача или нес-ко.

        Интегратор аргументирует, как и в этой дискуссии, такое решение тем, что все инциденты контролируются SD (он является их владельцем). ОК; но – раз владельцем ВСЕХ инцидентов и так является SD, зачем отдельно для этого использовать поле "ответственный"?

        И – кто конкретно контролирует ход решения – диспетчер, к-рый принял заявку, начальник смены диспетчеров или кто? И опять же – а почему именно 1ая линия  к-рый в основном интерфейс? Если это персонал смены, то интегратор предлагает нам ежедневную процедуру передачи инцидентов по смене.

  • Кротов Алексей

    В общем, вышли на четкое понимание причин несогласия. Интегратор считает, что в общем Inc manager и accountable, и responsible за обращение. Но т.к. его может на все не хватать, то он делигирует свое право на отчетность со стороны исполнителей 2ой линии сотрудникам 1ой линии, к-рые каким-то образом становятся его сотрудниками.

    Т.е. у нас получается 2 accountable в процедуре выполнения обращения – и Inc manager, и Service Desk Analyst. Но интегратор упорно утверждает, что SD Analyst в таком случае не accountable, а responsible.

    Коллеги, прошу подсказать – может, я теряю какую-то очевидную вещь из виду, почему интегратор прав, а я – нет?

  • Кротов Алексей

    Что ж, готов в молчании продолжать свой монолог =).

    Решил спросить признанного авторитета – ITSkeptic'а:

    "Can you answer for principal question – who is responsible for request when it's on 2nd support line?"

    Вот его ответ:

    "If I understand the question, there is no "official" answer I think.  My opinion is that service desk should always own tickets, and delegate tasks to level 2.  They transfer the ticket but they still have ultimate responsibility for ensuring it gets resolved.
    Others believe transfering a ticket also transfers ownership/accountability, but I don't think level 2 have the motivation for customer satisfaction."
     Вроде как понятно – they transfer the ticket, т.е. передают  обращение на 2ую линию, но при этом still have ultimate responsibility for ensuring it gets resolved. И опять 25, пока он не уточняет, что Others believe transfering a ticket also transfers ownership/accountability – т.е. мнение Роба Ингланда, что передача инцидента на исполнение (responsible) не должна  сопровождаться передачей ответственности за него (ownership/accountability).

    Меня в данном вопросе смущает факт, что 1ая линия может быть сменной. Кто в таком случае выполняет контроль обращений? Или все же имеется в виду не персональная, а коллективная ответственность 1ой линии – мол, приближаемся к сроку эскалации – любой сотрудник 1ой линии должен сделать … что? Вручную эскалировать? Если система автоматизации позволяет сделать автоматическую эскалацию – в чем задача 1ой линии – сообщить исполнителю, что сроки поджимают? Он и так это видит. Уведомить рук-теля рабочей группы и менеджера процесса?

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

      Алексей, хватит разговаривать самому с собой 🙂 Мы здесь!

      Я не считаю, что единственный способ обеспечить действенный контроль решения инцидентов – это поручить его L1, потому что все остальные заняты и вообще согласно ПСП "переживают за другое". В этом случае, как упоминал Роман Журавлев выше в этой дискуссии, за неумением организовать процесс мы подменяем его функцией, которая делает все то, что остальным неинтересно / непривычно. Но я согласен со Скептиком в том, что здесь нет официального и единственно правильного ответа.

      Я вижу две вещи, которые надо делать (мы в наших проектах их обычно делаем). Первая – прорабатывать вопрос ответственности и мотивирования менеджеров групп L2 / L3. Четкие метрики с целевыми значениями, регулярный контроль, премирование / депремирование, гамификация и все, что Вы сможете придумать. Вторая – максимально переносить функции регулярного контроля обработки инцидентов на систему автоматизации. Это во-первых позволит разгрузить L1, а во-вторых не слишком обострять вопрос "L2 работает, а L1 только контролирует". С точки зрения осознания ценности L1 здесь также полезно побороться за FLR.

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

      Вместе с тем я не вижу серьезной проблемы в организации контроля на L1 даже с учетом сменности. Это решается и процедурно, и ресурсно (например, выделением контролера), и инструментально. То есть да, так можно, но я бы все-таки сначала пробовал другой вариант. И как правило он получается.

      • Кротов Алексей

        По поводу контроля/ответственности 1ой линии за инциденты – в SO прямо указывается, что совмещения супервизора SD и inc Manager'а – рабочий вариант: "In many organizations the role of Incident Manager is assigned to the Service Desk Supervisor – though in larger organizations with high volumes a separate role may be necessary. In either case it is important that the Incident Manager is given the authority to manage incidents effectively through first, second and third line." И я не против контроля очереди обращений супервизором. Но – если его нет, то контроль, ИМХО, должен падать не ниже – на людей, сидящих на телефона, – а выше – на менеджера SD или просто выделенного менеджера процесса.

        Вторая — максимально переносить функции регулярного контроля обработки инцидентов на систему автоматизации. Вопрос – автоматизация не уберет ответственность. Т.е. если система зафиксировала нарушение, она должна эксалировать на accountable роль, к-рая будет иметь полномочия и должна будет принять решения. Если эскалация делается вручную оператором SD, это нисколько не делает его отвественным и имеющим право принимать решения. В связи с этим автоматизацию процесса в его описании я хотел бы максимально опускать. Есть автоматизация – отлично. Нет ее – есть регламент, по к-рому сотрудники отвечают за отправку кляузы генералу. А генерал/accountable все тот же и в 1ом, и во 2ом случае.

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

          Но — если его нет, то контроль, ИМХО, должен падать не ниже — на людей, сидящих на телефона, — а выше — на менеджера SD или просто выделенного менеджера процесса.

          Вот есть сигнализация и противоугонная система. Задача первой – обнаружить попытку угона, второй предотвратить. Так вот та часть контроля, которая связана с обнаружением отклонений и первичным сбором информации об обстоятельствах, не требует погон. А вот реакция и принятие управленческих решений – другое дело. Первая часть может быть в той или иной пропорции автоматизирована, возложена на L1, возложена на выделенных сотрудников вне L1. Что касается второй, то функциональные менеджеры могут иметь больше возможностей по корректировке действий своих подчиненных, чем менеджер процесса. Хотя все зависит от того, кто у вас является менеджером процесса.

          Вопрос — автоматизация не уберет ответственность.

          Ну а в чем же тут вопрос? Конечно Вы правы – не уберет. В моей жизни, как правило:

          – Accountable за выявление и устранение отклонений – менеджер процесса

          – Responsible за устранение отклонений – функциональные менеджеры (руководители "отклонившихся")

          – Responsible за выявление отклонений может быть и L1, и система автоматизации, и иногда другие роли (вплоть до представителей на стороне заказчика, хотя это не самый тривиальный вариант). Лучше – система: дешевле, надежней и менее конфликтно.

          • Кротов Алексей

            Дмитрий, благодарю. Обсуждение как-то прояснило ситуацию. Но до сих пор не могу понять, почему и коллеги, и интегратор упорно стоят на позиции, что раз 1ая линия может увидеть отклонение и выполнить роль "сигнализации", то и responsible за обращение тоже она.

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

              Так это достаточно просто выяснить. Я Вам свою позицию изложил и аргументировал. Теперь спросите коллег и интегратора: "Какие альтернативные варианты вы рассматривали? Почему вы считаете, что именно этот лучший? Обоснуйте, пжл". Задавать вопросы всегда интереснее, чем спорить 🙂

              Еще вопрос к Вам: а Ваша роль какова? Вы менеджер процесса?

              • Кротов Алексей

                Обоснование со стороны интегратора следующее: "SD больше бизнес-ориентированное поздразделение/сотрудники; в их интересах отслеживать и контролировать соблюдение SLA. Функциональные группы же – ресурс, и в их интересах ставить завышенные OLA, затягивать сроки etc., чтобы их не сорвать. Так что мы ставим инполнителей под контроль бизнес-ориентированных сотрудников 1ой линии, к-рых еще и мотивируем "пинать" 2ую линию".

                На мое замечание, что 1ая линия – это в нек-ром смысле растрельная должность, т.к. общение идет с недовольным пользователем + 1ая линия не самая экспертная по тех и бизнес вопросам, получаю ответ, что вот как раз нужно искать таких спец-тов 1ой линии, чтобы они были неприкосновенны для пользователей (т.е. тот не смел повысить голос на сотрудника; благая цель – я только за, но вот как это контролировать?), их опыт и понимание бизнеса были ценимы сотрудниками 2ой и они имели достаточный вес, чтобы "гонять" рук-телей функциональных групп (2ой линии). Ну и соответственную ЗП.

                Я опять же спрашиваю – что это за чудесный сотрудник, всеми уважаемый, ценимый, с высокой ЗП и сидящий на телефоне? А вот, грят, есть такие.

                Опять вопрос – что это за спец-ты 1ой линии, к-рые "гоняют" рук-телей 2ой? Ну, не  гоняют, уточняют коллеги, а извещают/эскалируют. Блин, это же делает система + это же не исполнение/контроль – а как раз та самая "сигнализация". Почему тогда дичпетчеры должны светиться, как ответственные?

                И так ходим по кругу. А если, замечают коллеги, у нас 3 параллельных задачи в обращении, кого мы укажем ответственным? У меня пока ответа нет, т.к. нужно думать – кто-то должен координировать выполнение этих работ. В "идеальном" ITIL это SD, к-рый передает задачи исполнителям, а потом получает рез-т обратно, но! Нам-то предлагают, что последующие работы инициируют исполнители. SD Analyst, пока не залезет в обращение, может быть даже не в курсе, что там к его задаче на 1 отдел уже приросло еще 10, пока 1ая эскалация не стукнет.

                Это не считая кучи других нестыковок предлагаемого процесса, к-рые меня смущают.

                Я – технолог проекта. + скорее всего буду менеджером процесса.

                 

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

                  Ключевой момент, в котором я согласен с Вами, заключается в том, что даже если на L1 возлагается ряд контрольных функций (что вовсе не является обязательным), это совсем не значит, что L1 должна становиться responsible за обработку инцидентов / запросов. Некоторые минусы такой конфигурации приведены здесь: http://www.realitsm.ru/2010/11/vzaimodejstvie/#comment-1118.

  • Armen

    Коллеги, 

    Данный выбор так же зависит от того, какой инструмент по управлению инцидентами Вы используйте. Если это HP ServiceDesk, то понятно, что можно назначить задание а не инцидент (хотя, я полагаю, что назначениеинцидента вернее), а если пользуйтесь системой Remedy HelpDesk, то там такой возможности нет, там назначается сразу же инцидент.

    Что вернее? Вернее, согласно моей практике, с Ремеди ХелпДеск, назначать инцидент, поскольку после обработки и назначения в теле инцидента аккумулируется вся информация по нему.

  • Курганов Вадим

    Коллеги,

    Последнему сообщению от Кротого Алексея уже более 1,5 лет, а вопрос по размещению точки ответсвености и точки контакта актуален.

    Давайте представим себе службу тех поддержки со следующими характеристики:

    1. Несколько десятков информационных систем
    2. Несколько десятков тысяч пользователей
    3. Несколько сотен групп обслуживания
    4. Первая линия – это специалисты которые только регистрируют обращение и назначают рабочее задание по справочнику (классифкатору групп обслуживания)

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

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

    Для выполнения рабочего задания, могут потребоваться разнные дополнительные действия:

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

    При этом добавляется и организационная и экспертная составляющая

    – Координация работ между группами обслуживания (вплоть до организации очного взаимодействия)
    – Понимание взаимодействия различных ИС организации и зон ответсвенности групп обслуживания

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

    Их реакция будет следующей. 1 линия забудет про заявку как только назначит ее на группу обслуживания. Группа обслуживания вернет рабочее задание со словами – не моя компетенция.

    Предложение:

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

    При чем можно организовать несколько таких групп, например иеррахически;

    на первом уровне – разрешения сложных инцидентов в рамках одной Информационной системы и обслуживающих ее технических средств

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

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

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

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

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