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

Задать вопрос!

Авторы блогов на портале Real ITSM готовы ответить на ваши вопросы!

Любой желающий может предложить тему для обсуждения или задать конкретный вопрос любому из авторов портала. Просто пришлите письмо с вопросом, описанием проблемной ситуации или темой для обсуждения на адрес info в домене realitsm.ru, или оставьте комментарий внизу этой страницы. Укажите, можно ли ссылаться на вас при публикации вопросов и ответов на портале.

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

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

Не забудьте подписаться на наш
бесплатный еженедельный дайджест!

[mc4wp_form id=”19945″]

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

  • Сергей

    Хотелось бы обсудить следующую задачу:
    Пусть мы имеем систему, которую используют 20 предприятий, общее количество пользователей 500, пусть на одном из предприятий 40 пользователей. Пусть система обслуживается с 9 до 18, время реакции 1 час, время закрытия типовой заявки на обслуживание 4 часа.
    Вопросы:
    1 какой инфориации не хватает, чтобы можно было рассчитать количество единиц службы поддержки (КЕСП)
    2. Как изменится КЕСП если указанное предприятие попросит уменьшить время реакции до 0,5 часа

    И общий вопрос — используются ли в практике управления услугами методы теории массового обслуживания?
    Спасибо.

  • Марина

    Подскажите, пжл, нужно ли разделять оперативное решение инцидента и полное решение инцидента? например: не формируется автоматически отчет (перестал работать функционал некой системы Х). например, пользователь может вручную создавать этот отчет (оперативное решение=обходной вариант), а исправление кода в системе Х (например, отчет не формируется из-за ошибки в коде) это уже полное решение инцидента? не смешиваются ли здесь понятия – решение проблемы?

  • Лялеко Владимир

    И снова о проблемах…в продолжении последнего семинара Евгения Шилова.

    Утрировано рассмотрим ситуацию с ошибкой в книге ITILv3 2007.

    В Книге в двух местах дано разное определение термина проблема. Из-за этого на экзаменах люди допускают ошибки и не набирают соответствующий бал.

    Проблемой в данном случае является ошибка в книге.
    Инцидентом низкий бал на экзамене.

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

    Вопросы:

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

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

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

    Если под обходным решением предлагается типовой механизм решения инцидентов при их появлении.. для меня это типовое решение инцидента, а не обходное решение проблемы…

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

    Хотелось бы услышать вашу точку зрения по данному вопросу 🙂 Может я где-то запутался 🙂

  • Ritil ITинович

    Приветствую
    На этом ресурсе много разной информации: обсуждений теорий и стандартов, небольших фрагментов проектов. Но полных реальных realitsm проектов здесь не нашел. Прочему бы не выложить несколько хорошо документированных проектов по ITSM, мониторингу, обсудить (экспертизу, так сказать, общественную), выбрать типовые решения, показать в них как теория сочетается с практикой и т.п. Хорошо бы и ценник показать, т.е. “что по чём». Вроде бы это должно входить в понятие: «realitsm». «Лучше один раз увидеть «realitsm» в реальных проектах, чем сто раз послушать». Уверен – эффект был бы куда выше.
    Вообще, как правильно то документацию оформлять по itsm – проекту? Какова структура продукта «realitsm»?
    Идею открытой библиотеки проектов (Ritil), в том числе и в itsm области, популяризирую на http://ritil.blogspot.com/2012/04/ritil.html
    Какие Ваши мнения на сей счет?

    С уважением,
    Ritil ITинович
    skeptic.ru@gmail.com

  • Сергей Посыльный

    Работаем с системой построенной по третьему ITIL (BMC Remedy – не сочтите за рекламу).
    В третьем ITILе по которому построена наша Remedy, обращения, инциденты, изменения разнесены по разным сущностям.
    Мы говорим своим специалистам: закончил работу с Инцидентом залезай и бери новый (в зависимости от приоритета и крайнего срока).
    Однако в нашей системе (да и презенташку MS видел – там та же проблема существует) для просмотра разных сущностей – разные «вьюшки».
    То есть специалист смотрит Инциденты в одной, переключается в другую и смотрит Изменения, в третьей Регламентные работы … производители ПО не озадачились созданием единого поля где можно было-бы увидеть все сущности сразу и отфильтровать их по приоритету и крайнему сроку для удобства специалистов и Старших команд поддержки.
    Может быть подскажут уважаемые коллеги что с этим можно сделать или как выкручивались из этой ситуации?

  • Alexander Peshkov

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

    Какая у вас практика, и какие есть плюсы/минусы у этих подходов?
    Каков процент проектов в общем объеме изменений, в первом и втором случаях?

  • Денис

    Здравствуйте, я являюсь одним из соучредителей небольшой компании которая занимается оказанием услуг населению в сфере ИТ.
    Сейчас наша компания стоит перед выбор программного обеспечения для управления инцидентами (service desk).
    Приоритетные задачи:

    1. учёт рабочего времени сотрудников.
    2. складской учёт
    3. оценка работы со стороны клиента.
    4. учёт выручки мастеров.
    5. Трудозатраты.

    и всё в этом духе 🙂

    Спасибо за внимание.

  • Dmitriy

    Приветствую.

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

  • Konstantin G

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

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

    Зравствуйте, или лыжи не едут…
    Я соверешенно запутался по поводу сертификации стандарта
    В общем я хочу получить официальное признание своего опыта и знания.
    Из всего многообразия сертификации мне наиболее подходит максимальный уровень ISO/IEC 20000 в области управления. Что нужно делать и сколько стоит?

  • Максон Клаксон

    Коллеги, прошу ответить на вопрос – кто внедряет itsm в ЦБ, название организации хотя бы. Очень нужно..

  • Василий

    Добрый день, уважаемые.

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

    Спасибо.

  • Aleksandr Meshkov

    Перспективы диагностики инцидентов «на лету»

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

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

    Более подробно алгоритм диагностики инцидентов «на лету» выглядит так.

    Первый этап. На стороне пользователя создаётся некое формальное описание инцидента (Снимок инцидента). Предполагается автоматическое создание и регистрация инцидента с использованием специального ПО.

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

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

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

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

  • Сергей Журавлёв

    Добрый день, Эксперты !

    Вопрос для программистов, не получается выравнить программную логику экрана для windows-клиента и web-клиента.

    Операция простая.

    Скрыть/показать элемент взависимости от значения полученных данных.

    В свойствах элемента я указываю –
    “условие отображения”: [contact.severity]
    (значение булевое)
    Элемент находится в доп. области (НЕ основная форма)

    В виндос клиенте – элемент прячется/показывается
    А web-клиент – никак не реагирует

    В какую сторону копать ?

    • Редакция портала Real ITSM

      Сергей, добрый день!

      На этом портале представлены эксперты несколько по другим вопросам, в первую очередь – по ИТ-менеджменту.

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

  • Александр

    Здравствуйте уважаемые Эксперты!

    Хотелось бы задать такой вопрос. В чём принципиальное отличие функциональной эскалации от иерархической? Очень важно показать иерархическую эскалацию на конкретных примерах.

    Зарание спасибо за ответ.

  • Дмитрий

    Добрый день.

    Пишет вам незадачливый студент, который выбрал в качестве своего диплома тему "Разработка и внедрение методики эскалации инцидентов на предприятии…" (грубо говоря повышение эффективности процесса эскалации), не подумав о том, что в принципе рекомендательный характер данных методик укладывается в 20-30 страниц, а по существу то написать и нечего. Может быть у вас есть какие то предложения и направления, в сторону которых можно работать? И буду благодарен, если порекомендуете какие-нибудь источники на данную тему, так как их маловато…

    Спасибо за внимание…

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

      Дмитрий, тема эскалации на самом деле весьма объемна. Вот в каком направлении я бы рассуждал:

      1. Виды эскалации (термины и определения)

      2. Функциональная эскалация
      2.1. Выбор между фиксированной и произвольной эскалацией (http://www.realitsm.ru/2012/09/functional-escalation/), в том числе связь со структурой каталога ИТ-услуг, влияние на отчетность
      2.2. Факторы, обеспечивающие эффективность эскалации (сбор нужной информации, оперативность оповещения, фиксация итогов обработки на каждой линии поддержки, предоствращение футбола, …)
      2.3. Влияния количества линий экалации на эффективность обработки инцидентов
      2.4. Назначение в группы и персональные назначения
      2.5. Автоматизированная функциональная эскалация
      2.6. Правила приема назначений в рабочие группы
      2.7. Ограничение времени на обработку инцидента на каждом уровне поддержки
      2.8. Участие в обработке инцидента L1 после привлечения более глубоких линий поддержки
      2.9. Изменение порядка эскалации при решении срочных инцидентов
      2.10. Особенности привлечения внешних подрядчиков

      3. Иерархическая эскалация
      3.1. Назначение и необходимость иерархической эскалации
      3.2. Факторы, обеспечивающие эффективность эскалации (доступность руководства, наличие необходимой информации, своевременность эскалации, …)
      3.3. Автоматизированная иерархическая эскалация
      3.4. Роль L1 в иерархической эскалации
      3.5. Особенность обработки major-инцидентов, роль major incident manager

      4. Контроль и измерение эффективности (метрики и KPI)

      5. Порядок и особенности внедрения (проектирования списка линий, вопросы автоматизации, разработка отчетности для контроля эффективности, связь с системой стимулирования, информирование персонала, …)

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

  • Евгений

    Добрый день!

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

  • Виктор Калинчиков

    Уважаемые коллеги!

    Поясните, пожалуйста, принципиальную разницу между CMDB, CMS и SKMS. Везде достаточно расплывчато определяется разница между этими понятиями, особенно разница между CMS и SKMS. Может быть есть какой-то ресурс, где можно прочесть об этом?

    Заранее благодарен!

  • Виктор Калинчиков

    Коллеги, прошу вас прояснить следующие моменты:

    1. Кто является обладателем прав на книги ITIL?

    2. Есть-ли такое понятие, как "официальный перевод книг ITIL" и почему книг нет в свободной продаже?

    3. Как определить, что перевод, например, на русский язык, является правильным (т.е. официальным)? Ктот имеет право переводить книги ITIL?

    Мои вопросы связаны с появлением многочисленных  вариантов перевода отдельных статей из книг и словаря терминов.

    Такое "разнообразие" не всегда помогает, например, готовиться к экзаменам.

     

    Спасибо!

    • Степан Хрулёв

      Виктор, добрый день.

      1. Говоря кратко, права на книги ITIL до недавнего времени принадлежали правительству Великобритании в лице TCO (The Cabinet Office) – одной из его подструктур, а управление осуществлялось компанией APMG. С мая 2013 года права на ITIL и вообще весь портфель лучших практик были куплены кампанией Capita, а управлением с 2014 года будет заниматься новая специально созданная компания AXELOS.

      2. Официального перевода на русский язык основных книг 3й версии не существует. Существует оффициальный перевод глоссария ITILv3 редакции 2011года. Из основных публикаций ITILv2 переведена синяя книга (ITILv2 Поддержка услуг). И еще есть перевод книг IT Service Management Foundation (ИТ Сервис-менеджмент. Вводный курс) и Metrics for IT Service Management (Метрики для управления ИТ-услугами). 

      3.Про опознание оффициального перевода вопрос довольно интересный. Я бы исходил из следующих соображений:
      а. На оффициальном переводе будут проставлены копирайты Crown Copyright (а теперь, наверное, Capita)
      б. Информация о переводя обязательно  появится на сайте itSMF России и на сайте http://www.best-management-practice.com/

      б*. Мы тоже врядли упустим возможность упомянуть о переводе здесь – на нашем портале 🙂
      в. Книга наверняка будет доступна в магазине itSMF России 
      Право переводить книги имеет тот, кто договорится с управляющей компанией (при этом управляющая компания обычно согласует такое решение с оффициальным издателем – TSO и с самим владельцем).

  • Елена

    В поисках экспертного мнения по определению термина "Производительность услуги" предлагаю обсудить состоятельность следующей трактовки:

    " Производительность услуги – это возможность (или способность) обеспечения согласованного уровня предоставления запрашиваемого объема услуги при установленных параметрах нагрузки на ресурсы."

    Ваше мнение?

  • ITSM вопрос

    Расскажите пожалуйста преимущества (пользу) и недостатки (затраты) вариантов:

    1. Известная ошибка это статус проблемы и тогда в системе автоматизации один объект.

    2. Известная ошибка и проблема это 2 отдельных объекта.

  • Владимир Михайленко

    День добрый!

    Немного философский вопрос, но очень интерисует ответ на него. Возможно ли построение Change Management без CMDB, например только на картах ИТ-услуги?

    Спасибо!

  • Андрей

    Коллеги,

    кто нибудь может внятно объяснить, зачем стоит заводить в CMDB CI типа "Услуга" ?  

    Рассмотрим случай, когда в информационной системе есть сущности типа "услуга" за рамками CMDB (например отдельная папка SLM и отдельная папка CMDB в OMNITRACKER). Понятно, что каждая CI должна быть связана с услугой, но для этого не обязательно связывать СI типа "сервер" с CI типа "услуга". Проставили в карточке CI в поле услуга нужную услугу и все. На деле же часто вижу примеры CMDB как дерево CI-ев, где есть CI в традиционном понимании (ПО, Железо, конфигурации серверов и тд) и CI типа "услуга". Есть ли ответ на мой вопрос, отличный от "а зависит от важего желания, инструментария etc"? 

     

  • Андрей

    Коллеги!

    Расскажите, можно ли активно развивая процесс управления рисками, заменить или покрыть управление проблемами?

  • Сергей Зайцев

    Добрый день, коллеги!

    В ходе работы на ITSM-проектах неоднократно сталкивался с ситуациями, когда в ИТ-подразделениях одновременно внедряются процесс управления изменениями (в соответствии с рекомендациями ITIL) и управление (ИТ-)проектами. Зачастую внедрения осуществляются при поддержке различных "спонсоров". Возникает, с одной стороны, необходимость разграничения сфер ответственности и задач управления изменениями и пректами и, с другой стороны, вопрос их стыковки и взаимодействия.

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

  • Наталья

    Коллеги, добрый день!

    Меня зовут Наталья, я представляю "Манн, Иванов и Фербер", издательство максимально полезных книг (m-i-f.ru)

    Хочу поделиться нашей новинкой – «Remote» http://www.mann-ivanov-ferber.ru/books/paperbook/remote_office_not_required/ Книга "Remote. Офис не обязателен" – манифест удаленной работы. Зачем это нужно, как эффективно организовать и поддерживать, для кого возможен такой формат? Авторы книги (они же авторы бестселлера Rework) подробно разбирают все «за» и «против». И убедительно доказывают, что преимущества удаленной работы во многом перевешивают ее возможные недостатки.

    Будем рады, если вы напишите отзыв или опубликуете анонс о данной книге на вашем ресурсе. Интересно Вам такое предложение? Прислать верстку или бумажный вариант?

    Заранее благодарю за ответ.

    С уважением, Наталья, Ассистент продюсера проектов Издательство "Манн, Иванов и Фербер"

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

      Наталья, добрый день!

      Мы любим хорошие книжки, так что присылайте. Если Remote будет такой же хорошей, как Rework, то за отзывом о книге дело не станет.

      Я напишу Вам по адресу, который Вы оставили.

  • Александр

    Добрый день, коллеги!

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

    С уважением, Александр.

  • Oleksandr Vinnytskyi

    Добрый день, коллеги

    Возник следующий вопрос: одним из важных результатов работы процессов входящих в Service Design является SDP (Service Design Package), который активно используется процессами Service Transition и Service Operation, а в рамках какого процесса создается собственно перечень тех документов и шаблонов, которые должны быть созданы при проектировании сервиса или значительного изменения?

  • Рафхат

    Добрый день!

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

    Какая практика обработки запросов существует в подобных случаях? Как правильно/прозрачно/просто донести до автора запроса об увеличении сроков исполнения запроса и при этом корректно считать соответствующую метрику процесса?

  • Роман Люблинский

    Уважаемая редакция,

    прошу рассмотреть вариант “оптимизации” вашего замечательного дайджеста:

    посылать статью полностью в письме, а ссылку “Читать на портале” заменить на “Комментировать на портале”.

    Почему: читаю, в основном, в пути, не всегда в зоне покрытия мобильного интернета – переходы по ссылкам – это боль. А письмо синхронизировано на телефон еще в офисе 🙂

    Не думаю, что это негативно скажется на посещаемости портала.

    Спасибо!

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

      Роман, добрый день!

      Благодарю за рац.предложение.

      Некоторое время назад мы выпускали дайджест с полными текстами заметок, но это многим читателям не понравилось: обычно за неделю у нас появляется не меньше 4-5, а бывает и до 6-7 заметок, дайджест выходит длинным и неудобным для чтения. Поэтому от такой идеи мы отказались в пользу анонсов.

      Для Вас могу рекомендовать подписку на RSS: в ленту мы отправляем полные тексты заметок.

      • Роман Люблинский

        Спасибо, постараюсь почитать в виде RSS. Хотя, с этим есть другая “засада” – RSS-а нет на телефоне 🙂

        6-7 заметок, дайджест выходит длинным и неудобным для чтения. 

        В начале дайджеста ведь ссылки на конкретные статьи внутри письма 😉

        Но, не смею настаивать.

  • Игорь

    Добрый день.

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

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

    Спасибо.

  • Дмитрий

    Доброго времени суток!

    Подскажите, пожалуйста, поставлена задача определить влияние IT на индекс потребительской лояльности (NPS), точнее на детракторов. Есть ли в Вашем обширном багаже какие-либо методики для расчета, либо в каком направлении ее возможно проработать.

    Сфера деятельности – Банковский сектор. 

    Свои наработки:

    Принять от 3 и более коэффициентов (1-% доступности систем, 2- оценка работы систем менеджером банка, либо его рук-лем, 3- оценка работы/обслуживания клиента)

    Сопоставить полученные данные к периоду времени.

     

    Либо по формуле NPS:

     

    Например, Детракторы(D) – 18, Промоутеры(P) – 72, Нейтралы(N) – 20 :всего 110 человек, Показатель мониторинга(M) – 97.5%

     

    Выходит, что:

    NPSIT=(97,5*18)/110=15,9-18=+2.1D по вине недоступности сервиса

     

     

    Верен ли какой-нибудь из подходов, или всё гораздо проще/сложнее?

     

    Заранее благодарен за какую-либо информацию. 

  • Иван

    Добрый день!

    Я уже являюсь подписчиком. Как я могу получить  аудиокнигу Романа Журавлёва «Иллюстрированный ITSM»?

    Спасибо.

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

      Иван, Вам нужно подписать на дайджест пять своих друзей, и наверняка кто-нибудь из них поделится с Вами аудиокнижкой.

      Шутка 🙂

      Ссылку на книгу отправил вам на оставленный email.

  • Александр

    Добрый день, коллеги!

    1. Где можно взять определение слов Техническая поддержка, Сопровождение, Техническая эксплуатация?

    Не понятно чем они друг от друга отличаются.

  • Анатолий

    CSI: Постоянное совершенствование услуг.

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

    Например,

    Шаг 1 — Регистрация улучшения

    Шаг 2

    …

    Шаг N -1

    Шаг N — Улучшение реализовано

  • Сергей

    Вопрос к Дмитрию Исайченко

    Реализуем метрики согласно вашей замечательной книги

    Сейчас застопрорились на метрике TPI в рамках РГ (стр.39-42 книги формулы 8-10)

    Рассмотрим ситуацию в рамках выполнения обращения привлечены в рабочие группы. Они работают параллельно. 

    Пусть обращение хочу хорошую погоду (не придирайтесь – это пример)

    SLA (T) по обращению 8 часов

    1 рабочая группа задача убрать снег

    2 Рабочая  группа разогнать облака

    1 Рабочая группа справилась в срок и все сделала за 2 часа

    2 Рабочая группа справилась за 12 часов и нарушила срок

    Для РГ2 TPI = 0

    А для РГ 1?

    0,75 – согласно формуле?

    Или же 1 ?

    В чем суть вопроса. Приведенные формулы хороши для ситуации приведенной на рисунке 8, т.е работ проходящих последовательно.

    А как правильно поступать при параллельных работах? 

    Обращение в целом нарушено, но есть вина в данном нарушении 1 РГ?

  • Вячеслав

    Доброго времени суток.

    Вопрос к личному опыту по Support groups.

     

    Какие ключевые критерии вы бы посоветовали выбрать необходимыми и достаточными, для выделения отдельных Support Groups.

    Интересует как с точки зрения здравосмыслия Support model, так и с точки зрения реализации в ITSM приложении.

     

    Вопрос вызван тем, что при рассмотрении организации достаточно большого размера и ширины профиля, логичное желание выделить группы по матрице Операционный уровень/Сервис влечёт за собой желание пользователей системы плодить группы сотнями…

     

    Поэтому интересует практический опыт.

    Заранее благодарю

  • Ярослав Максименко

    Уважаемые коллеги, добрый день!

    Просьба посоветовать хорошие практики по учету прав доступа к информационным системам (бизнес-сервисам).

    Цель: учесть возможные права доступа к каждой системе и выданные права доступа каждого пользователя к каждой системе. Использовать это в заявках на запрос, изменение, отключение прав, для отчетности и аудита прав.

    Сейчас это представляется мне так: для каждого права доступа к системе создается отдельный класс  CI в CMDB. К CI "Информационная система" привязываются все CI "Право доступа…", имеющие к ней отношение. Пользователи привязываются к CI "Право доступа…", в соответствии с выданными им в реальности правами.

    Есть ли какой-то другой подход к решению такой задачи?

    Заранее благодарю!

  • Игорь

    Добрый день, коллеги!

    в книге itsm – руководство по измерению есть ссылка на то, чтоб не забывали про бенчмаркинг по метрикам, которые публикуют аналитические агенсства. где можно посмотреть на эти метрики? оччень нужно и важно

  • Дмитрий

    Коллеги, добрый день.

    Интересует как правильно связывать инциденты с затронутыми ими бизнес-сервисами.

    Пример 1: клиент не смог перевести средства на счет телефона через интернет-банк и обратился в поддержку -> зарегестрировали инцидент с привязкой к бизнес сервису "Платежи и переводы в ИБ". Тут всё понятно.

    Пример 2: Ответсвенный специалист обнаружил сбой в процессинговой системе (либо пришел алерт от системы мониторинга). Этот сбой влияет / может влиять не только на проведение платежей в ИБ, но на операции в банкоматах / ТСП / интернете и т.п. 

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

    – Реально ли первой линии понимать все взаимосвязи систем и бизнес-сервисов? 

    – Если представить, что пример 1 и пример 2 случились в одно время, то что делать с пользовательскими инцидентами (в которых выбраны конкретные затронутые бизнес-сервисы) и инцидентом, который был зарегестрирован ответсвенным / алертом (в котором выбрано несколько затронутых бизнес-сервисов). Их нужно связять? Какой делать главным? Как учитывать выбранные бизнес-сервисы во всех инцидентах?

     

    Поделитесь опытом в этой теме, пожалуйста.

     

     

     

  • Вадим Древин

    Добрый день, коллеги.

    Вопрос к Дмитрию Исайченко.

    В книге "ITSM Руководство по измерению" на странице 28 приведена формула (4) по расчету интегральной оценки. Есть такое ощущение, что она работает не корректно. Поясню:

    Рассмотри простейший пример. У меня есть два KPI, и оба находятся ровно посередине между целевым и пороговым значением, то есть в середине ЖЕЛТОЙ зоны и т.о. оба равны 50% (или 0.5).

    Рассмотрим несколько примеров применения этой формулы: (а), (б) и (в).

    а) Если веса у них одинаковы и равны 1, то интегральная оценка у них равна BS=0.5*0.5=0.25 (или 25%).

    Если же веса разные, то очевидно что интегральная оценка будет больше 25% (что вполне логично), т.к. один из KPI (с максимальным коэффициентом) так и останется в произведении как 0.5, а второе увеличится, поскольку возводя число меньшее единицы в степень также меньше единицы получим число большее чем исходное, но по прежнему меньше единицы.

    б) В этом примере пусть будут веса равны 2 и 1 соотв-но. Имеем операнды произведения: первое 0.5, второе 0.5^(1/(2-1+1))=0.5^0.5=0.71. Итого: BS=0.5*0.71=0.355 (или 35.5%).

    в) Поскольку сказано, что "веса это целые положительные числа, представляющие относительную значимость друг от друга" (стр.25 и сноска на стр.28), то в примере (в) я приму веса равными 4 и 2 соотв-но. И ожидаю получить такой же результат, как и в примере (б). Считаем: первый операнд 0.5 [ 0.5^(1/(4-4+1))=0.5^1=0.5 ], второй операнд 0.5^(1/(4-2+1))=0.5^(1/3)=0.5^0.(3)=0.79. Итого: BS=0.5*0.79=0.395 (или 39.5%).

    Результат в примере (б) и (в) не совпал, и т.о. можно сделать вывод, что в формуле есть ошибка.

    Осмелюсь высказать предположение, что наименьший коэффициент должен быть равен 1 (единице) чтобы формула работала, но в этом случае остальные коэффициенты следует разрешить ставить дробными числами. Т.к. при относительной значимости, например, 3 к 2, коэффициенты при меньшем равным единице будут равны 1.5 и 1. Если применить текущую формулу к 1.5 и 1, то получится BS=31.5%; если же 3 и 2, то BS=35.5%. Прошу обратить внимание, что при коэффициентах 3 и 2 результат получился такой же, как и при коэффициентах 2 и 1, и более того он получится таким же при коэффициентах 1000 и 999. Что совсем не правильно.

    Не могли бы вы пояснить, как все-таки правильно использовать формулу? Спасибо!

    P.S. Также хотел бы указать на замеченную неточность в книге – сноска 36 на стр.99. Там сказано, что на графиках "японские свечи" отображаются среднее и предельные значения котировок за заданный интервал времени. Хотел бы заметить, что в японских свечах средних значений НЕТУ, есть только предельные (как указано в книге) и значения на начало интервала времени и на конец. Т.о. на японской свечи 4 значения, но среднего там нет :).

  • Эльдар

    Если пользователи начинают плодить заявки относящиеся к одной общей проблеме, будет ли правильным объединять их в одну?  Или же правильнее создание отдельной "главной" заявки и работать по ней, а по результатам закрывать заявки полученные от пользователей? 

  • Альберт

    Коллеги, добрый день!

    Есть вопрос по определению ответственности по просрочкам в обращениях.

    Суть проблемы в следующем, в Service Desk настроено, что кто последний выполнил обращение, того и заявка в отчёте, но в случае же, если данное обращение просрочено, то просрочка также назначается на последнего исполнителя.

    На мой взгляд, это несправедливо, поскольку те сотрудники по чьей вине обращение просрочено избегают ответственности, передавая её на других исполнителей. 

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

    Спасибо

  • Ксения

    Здравствуйте! 

    Подскажите пожалуйста студенту, где можно найти сравнение методологий ITIL, COBIT и ISO 20000 между собой?

  • Ксения

    И снова здравствуйте!)

    Хотела еще спросить – можно ли по каким-либо параметрам оценить эффективность работы HelpDesk, который представляет собой форму заявки дли ИТ-службы, и размещенный на корпоративном портале, реализованный в среде MS SharePoint? Обсобенно если нет возможности узнать, сколько обращений и в какие сроки были удовлетворены, довольны ли обратившиеся и тд. То есть имея лишь, по сути, "исходные данные" – саму форму заявки и отображение поступивших заявок в виде таблицы, с указанием описания возникшей проблемы, состояния на данный момент(принялись ли за исполнение, завершена), информацией об обратившемся и об исполнителе?

    • Алексей Юсов

      Можно теоретически измерить уровень криков пользователей в децибелах ). Обычно такой показатель удовлетворённости обратившихся так или иначе присутствует. Других объективных критериев при заданных условиях не посчитать. Были бы хотя бы даты создания и закрытия обращения, уже хоть что-то. А так – нет… только внешние акустические **** или эмоциональные флюиды и взгляды несчастных (или счастливых. А почему бы и нет?!) пользователей.

      • Алексей Юсов

        Почему-то фильтр воспринял слово "ко ле ба ни я" в связке с  "только внешние акустические " как нечто непечатное. Почувствовал, наверное, недоброе из контекста )))!

        • Ксения

          =D

          Кстати, в форме заявки есть даты обращения и закрытия, они же потом отображаются в общей таблице)

          То есть нужны так или иначе статистические данные?(

          • Ксения

            *** для того, чтобы можно было сказать что-то в духе: "мы довольны, нам ничего дополнительного не нужно" или же "необходимо изменить то, то и то.." или ввести что-либо другое

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

          Эти фильтры такие фильтры…

          Забавно, что именно этот плагин, который делает нам тут фильтр, не обновлялся разработчиком с 2009 года. То ли он идеален, то ли русский язык остановился в своём развитии.

  • Олег Цыганов

    Всем привет. 

    Внимательно и не один раз прочитал статью "Главная проблема ITIL Expert'ов" в разделе статей Cleverics. В статье предлагается поставить себя на место директора компании и сформулировать цели для ИТ-директора. 

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

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

  • Maryna

    Здравствуйте!

    Совершенствуем SLA и думаем над определением "Стандартная работа сервиса". В обсуждениях качества обслуживания с Заказчиком нам явно не хватает единого определения. Сейчас оно свое у каждой из сторон и даже разное у разных представителей сторон. Это очень усложняет сотрудничество.

    Поделитесь опытом, пожалуйста, как выйти из этой ситуации.

    Спасибо!

    Марина

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

      Здравствуйте, Марина! Мы создали отдельную тему, где можно обсудить Ваш вопрос. И в ней уже есть комментарии!
       

  • Балжан Курманова

    Добрый день,

    Хотелось бы узнать опыт коллег. Каким способом можно опитимизировать работу 2 линии ПП, тем самым разгрузить специалистов и приучить Заказчиков к подаче запросов через АС и структурировать их запросы?

    Поясняю ситуацию: 2 линия ПП по 10 ИС (только функциональная часть), на каждую ИС (в каждой примерно от 500 и выше пользователей) определены по 2 специалиста, в задачи которых входит не только отработка поступающих запросов от пользователей ИС (ведется учет в АС), но и сопровождение ИС (отработка корреспонденции, взаимодействие с Заказчиком, защита отчетов у них, взаимодействие с 3 линии, содействие при сбоях ИС, отчетность, актуализация документации). Запросы от Заказчиков поступают в устном порядке и по почте (в основном предоставить справки, информации и объемные выгрузки, стат. данные из ИС ), требуют незамедлительного выполнения либо в сжатые сроки (бывают случаи запрашивают одно, при предоставлении требуют изменить либо дополнить),  соответственно специалисты отвлекаются на их запросы, тем самым имея риски просрочить запрос от пользователя в АС (установлено регламентное время в зависимости от типа обращения). В связи с чем не могу вести полный учет трудозатрат сотрудников на отработку всех запросов, так как часть из них (от Заказчика) не фиксируется в АС.  Нет возможности увеличения штата.

  • Rafhat Osmonov

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

    В чем разница, какое назначение, охват и где проходит граница между Request Fulfilment и Service Request?
    И конечно же в чем ценность вышеуказанных процессов?

    Если вы обладаете ссылками на описание, поделитесь, буду благодарен.

    Спасибо!

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

      Рафхат, добрый день!

      Вы пишете про два процесса, однако, второй процессом не является. Service Request (запрос на обслуживание) является объектом управления процесса управления запросами на обслуживание (Request Fulfilment).

      Уточните, пожалуйста, о каком втором процессе идёт речь?

      • Rafhat Osmonov

        Видимо это можно считать первым ответом на мой вопрос.

        С учетом вашей корректировки я переформулирую вопрос:

        В чем особенность, какое назначение, охват и ценность процесса Request Fulfilment?

        С какой целью в этом процессы выделен объект Service Request? Каково его назначение и где проходят границы?

  • Дмитрий

    Добрый день,

     Внутри команды Service Managers  возникло бурное обсуждение, откуда должен предоставляться Problem Management, так как в ITIL нет четкого описания ( или мы его не нашли), кто за это отвечает ( понятно, тут не обойтисть без Problem Manager)  и откуда  (ServiceDesk?) , есть лишь описание , что проблемы поднимаються со 2-й линни в Problem Management процесс. Cреди вариантов есть такие мнение:

    1) Не должен предоставляться Service Desk, так как возникает конфликт интересов, и всегда должен предоставляться на уровнях  2 или 3 линий поддержки, которая обязательно находится не в ServiceDesk

    2) Предоствляется из Service Desk, так как процесс позволят планомерно уменьшать количество инцидентов и т д и т п

    Вопросы:

     1) Что говорит ITIL по этому поводу? и говорит ли вообще? 

    2)  А  где у Вас на проектах находится Problem management? И какие вы видите сложности в этом?

     

    Спасибо 

  • Денис

    Добрый день.

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

    Первая иллюстрация

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

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

    Вторая иллюстрация

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

  • Антон

    Коллеги, приветствую!

     

    Хотелось бы обсудить тему качества процессов.

    Предположим процесс описан, утвержден, автоматизирован. Люди обучены и работают по регламентам (так или иначе).

    Есть задача контролировать качество процесса.

     

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

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

     

    Инетесно ваше мнение, коллеги.

     

     

  • Станислав

    Добрый день!

    Не подскажете, на текущий момент известны какие-нибудь реализации стандарта INCITS 494-2012 (Role Based Access Control Policy Enhanced), или подходы к реализации, поддержка в фреймворках? Интересует именно реализация динамических ограничений (в частности, на основе атрибутов).

    Или может быть кто-то подскажет другое решение?

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

    Небольшой пример ролей и привилегий из нашего проекта "Роль{permission1, …}":
    * Врач{чтение_своих_пациентов}
    * Гл.Врач{чтение_своих_пациентов, чтение_пациентов_в_своей_организации}
    * Статистик{чтение_отчет_#1_по_своим_пациентам}
    * Гл. статистик{чтение_отчет_#1_по_пациентам_в_своей_организации}

    Динамически добавляемые привилегии (в зависимости от типа организации):
    * чтение_пациентов_в_подчиненных_организациях
    * чтение_отчет_#1_по_пациентам_в_подчиненных_организациях

    Динамические ограничения:
    * Федеральный округ – чтение пациентов/формирование отчета_#1 ограничено конкретным федеральным округом
    * Федеральный субъект – чтение пациентов/формирование отчета_#1 ограничено конкретным федеральным субъектом

    Понятно, что эти ограничения можно представить в виде привилегий:
    * чтение_пациентов_региональный уровень
    * чтение_пациентов_федеральный уровень

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

    К примеру, если добавиться временное ограничение: "Роль может выполнять операцию над объектом только по прошествии определенного времени после события".
    Очевидно, такое ограничение будет сложно реализовать через привилегии. 
    А раз так, то почему бы ограничения: "мои_пациенты", "моя_организация", "подчиненные_организации", "региональный_уровень", "федеральный_уровень", "привязка ко времени" не вынести в отдельный
    механизм?

    Я так понял, стандарт INCITS 494-2012, а точнее его раздел, посвященный динамическим и статическим ограничениям, должен как раз решать данную задачу?

  • Кирилл

    ЗдПланируете ли вы запускать в России курс по RESILIA?

    Если да, то когда?

  • Кирилл

    Жаль. 🙂

  • Станислав

    Добрый день!

    Вопрос касается области управления доступом (access control, rbac)

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

    Могу по другому сформулировать вопрос.
    Наш проект начинался с небольшого набора функционала для которого достаточно было 5-6 ролей.
    С течением времени проект разрастался и новый функционал требовал более тонкой настройки прав доступа.
    У команды, на данный момент, нет опыта работы с такими методологиями, как, например, Role engineering (top-down, bottom-up, Hybrid), как описано в статье https://blogs.oracle.com/OracleIDM/entry/enterprise_role_definition_best_practices

    Какие бы вы дали советы команде 

    с чего начать (к каким материалам стоит обратиться),

    понять нужен или не нужен нам Role engineering

    чтобы в конце-концов выстроить грамотный процесс проектирования и поддержки подсистемы управления доступом?

  • Ленар Рахматуллин, рук. отд. Сервис Деск, ICL Services

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

    Могу предложить следующие 3 ключевых, с моей точки зрения, ожидания:
    1. Service Desk должен быть связующим звеном в ИТ-организации для координации работ между разными группами, независимо от из принадлежности к компании или стороннему поставщику;
    2. Service Desk должен обеспечивать постоянное улучшение пользовательского опыта (End User Experience) за счет регулярного тренд-анализа, идентификации и решения проблем и применения других практик continuous improvement;
    3. Оператор Service Desk, должен индивидуально подходить к каждому обращению, учитывать конкретную сложившуюся у пользователя ситуацию и ее влияние на бизнес-процессы, подстраиваться под поведенческие особенности конкретного пользователя.

    Сознательно не говорю об SLA, поскольку на практике, это, как правило, договор. Договорные обязательства нарушать нельзя. Это сродни границе между государствами – за нарушение границ следует  неотвратимое наказание. Но SLA – далеко не все, что ждет от Service Desk и от ИТ бизнес.

    Каковы ваши ожидания от службы Service Desk?

  • Анна Закускина

    Здравствуйте.

     

    Хотелось бы спросить совета в отношении курсов по управлению программистскими проектами и бизнесанализу в контексте разработки.

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

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

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

    Посоветуйте что-нибудь, пожалуйста!

  • Александр Т

    Добрый день!

    Задача: произвести модернизацию ИС при помощи подрядной организации.

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

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

    Спасибо

    • Nargiza Suleymanova

      Если говорить о best practices, то в Prince2 как раз описаны роли в проектах с кругом задач и ответственностью. Но я бы не стала называть ролями перечисленные вами специальности (аналитик, программист и т.д.).

    • Елена Шушковская

      Александр, спасибо за вопрос! Обсуждение открыто по ссылке.

  • Дмитрий

    Добрый день, уважаемые коллеги.

    Помогите разобраться с ситуацией просчета показателя KPI как своевременность обработки и поиску доли вины по просроченным инцидентам. На вашем ресурсе я уже изучил статью http://www.cleverics.ru/ru/subject-field/articles/589-incident-management-measurement, но остался ряд вопросов.

    Представим ситуацию, когда был просрочен инцидент и в процессе решения было несколько смен услуг и несколько смен групп ТП. SLA по услуге = OLA(Время 1ЛТП)+OLA(Гр ТП в зависимости от выбранной услуги).

    Допустим инцидент по первоначальной услуге надо было решить в срок 10 дней. 1ая ГР ТП была занята или просто приступила к решению на 5ый день. В итоге было установлено, что услуга выбрана не та и проблема не в ее компетенции. Затем была произведена смена услуги. SLA по этой услуге составляет 2 дня. Т.е. у нас получается ситуация когда на следующую группу упал уже просроченный инцидент, так как SLA/OLA начинает свой отсчет с момента создания инцидента.

    Вопросы:

    1. Как мы можем просчитать объективную долю своевременности обработки инцидента. Ведь первая ГР ТП действовала в рамказ своего установленного времени OLA? По своему времени у них все в порядке. Вести расчет R и W относительно времени SLA по ктоторому закрывался инцидент не совсем корректно. Как вариант Веса и рейтинги можно расчитывать относительно своего для каждой услуги и Гр ТП времени OLA. Т.е. сколько времени они удерживали инцидент.

    2. Как описано в примере выше, 2ая Группа ТП получила уже просроченный инцидент, как по SLA, так и по своему времени OLA. Если поменять смысл OLA на следующий.Что вне зависимости от того менялась или нет услуга, SLA начинает свой отсчет от момента регистрации инцидента и следующая группа может получить уже просроченный инцидент по SLA. Но время OLA при переназначении будет начинаться с момента переназначения, т.е. у группы будет оставаться свое регламентированное время на решение OLA. А расчет своевременности по просроченным инцидентам мы будем вести: 1 по просроченным инцидентам. 2. R и W будем высчитывать отностительно OLA1,OLA2… OLA N. В данном случае у нас получается что общее время OLA выходит за пределы SLA по услуге. Хочется услышать мнение экспертов по данному поводу, ведь время OLA не может быть больше SLA.

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

    Пример. У пользователя проблема с почтой( не отправляются письма). Заводится инцидент по услуге "Проблема почтового ПО" и в рамках инцидента создается первая задача для ГР ТП1 "проверка почтового ПО". ГР ТП1 устанавливает, что проблема не связана с ПО. Далее в рамках инцидента создается задача 2 – "Проверка сети" в ходе решения которой ГР ТП2 устанавливает, что это не проблема сети. Создается задача 3 – "Проверка ПК" – инцидент закрывается.

    В этом случае что бы гарантировать Заявителю конечное время SLA мы должны понять и определить какие дополнительные задачи могут возникнуть, что бы просчитать и гарантировать финальное время SLA. SLA =  OLA1+OLA2+…+OLA N. Но такой подход выглядит сложно реализуемым. Ваше мнение?

     

  • Андрей Вишняков

    Хотел попросить коллег поделиться информацией – какие основные меры направлены на обучение 1 линии так, чтобы при функциональной эскалации на 2/3 уровень приходили качественно обработанные обращения (с точки зрения 2/3 линии) в условиях постоянно изменяющихся ИТ-услуг и характера обращений…

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

    Либо мы можем лишь в большей или меньшей степени уменьшать "боль"  некоторыми мерами, например:

    – вводом реестра по каждой ИТ услуге т.н. опросников пользователей для 1й линии (составленного специалистом 2/3 линии) по входящим обращениям

    – регулярными презентациями силами старших специалистов технологий, лежащих в основе ИТ-услуг с целью повысить понимание 1 линией

    – дать 2/3 линии возможность давать оценку качества обработки обращения, в результате которой обращение возвращается на доработку и в итоге влияет на KPI 1 линии

    – что-то еще..

    Есть мысли на этот счет?

  • Никита

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

    Хотел бы услышать мнения экспертов по поводу следующего способа изменения срока решения инцидента при изменении его (зафиксированного) влияния.

    Для упрощения возьмем следующую модельную ситуацию.

    Срок решения инцидента определяется его влиянием.
    Шкала влияния состоит из двух значение:
    1 – за один час инцидента с таким влиянием бизнес теряет 1$
    2 – за один час инцидента с таким влиянием бизнес теряет 2$

    Сроки решения инцидентов:
    1 час – для инцидентов с влиянием 1
    30 минут – для инцидентов с влиянием 2

    Таким образом при решении инцидентов вовремя бизнес теряет максимум 1$ независимо от влияния инцидента.

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

    В случае когда меняется зафиксированное влияние предлагается поступать следующим образом:
    1) В случае если ранее влияние было неверно определено, пересчитывать срок решения инцидента начиная с момента регистрации инцидента.
    2) В случае если влияние на самом деле изменилось, пересчитывать срок решения сохраняя % времени, оставшийся на решение. Например, если пока влияние инцдента было на уровне 2 мы работали с ним 15 минут (50% времени, отведенного на решение), то при изменении влияния на 1 срок решения пересчитается так, чтобы у нас осталось ещё 30 минут (50% от времени, отведенного на решение для влияния 1).
    Таким образом мы сохраним максимальное влияние на бизнес на необходимом уровне.

    Какие плюсы/минусы вы видите в данном подходе?
    Как вы поступаете с сроком решения инцидента при изменении его влияния?

  • Дмитрий

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

    1. Поставляемая услуга

    2. Партнерская услуга

    3. Описание этапов жизненного цикла: 

    Планируются к внедрению

    Тестовая эксплуатация

    Пилотный проект

    Опытная эксплуатация

    Промышленная эксплуатация

    Планируется к выведению из эксплуатации

    Выведен из эксплуатации

    4. Какие есть классы безопасности? (один содержит пользовательские данные, второй нет. Как они называются?)

    Спасибо большое за ответы!

     

  • Abeke

    Добрый день! Хотел бы узнать, в чем разница между ITIL и COBIT5.

  • Арсен Юрьевич

    Добрый день, подскажите где можно сдать экзамены удаленно? Обучение я буду проходить в Москве в январе и в феврале в Учебном Центре «Специалист» при МГТУ им. Н.Э.Баумана, но потом территориально буду находится во Владивостоке. Хотелочь бы сдать удаленно следующие экзамены на русском языке, это возможно?

    ITIL® Foundation

    ITIL® Intermediate OSA Module

    ITIL® Intermediate SOA Module

  • Александр

    Добрый день!

    Хотелось бы увидеть мнение относительно завершения партнёрских отношений между AXELOS и EXIN с 2018 года: как теперь будет быть Cleverics, кто стал единственным экзаменационным институтом (партнером по портфелю AXELOS), что слышно от агента "извнутри"? 

    https://www.exin.com/RU/en/media/news/120/2017/exin-and-axelos-end-their-partnership-in-2018

    Спасибо и с праздниками!

    • Игорь Гутник

      Александр, спасибо!

      Действительно, с 1 января 2018 года AXELOS будет работать через единственный экзаменационный институт (EI) – PEOPLECERT.

      Очевидно, что основной риск [любой] монополизации – это повышение цен (и аналогичные возможные побочные явления монополизации).
      Во всём остальном ни партнёрам, ни уж тем более конечным заказчикам беспокоиться не о чем.
      Аккредитация по продуктам AXELOS проводится всеми EI по единым правилам, определяемым правообладателем (AXELOS). Разумеется, у нас возникает необходимость в проведении некоторой «бумажной» работы. Но она уже ведётся, и за предстоящий год, конечно же, будет завершена. Тем более, что у нас уже весьма продолжительное время есть прямые формальные отношения с AXELOS. И с PEOPLECERT работа тоже давно ведётся.

      Так что у Cleverics всё хорошо. Самый ценный сервисный актив (service asset [ITIL]) компании – наши сотрудники. Следовательно, с точки зрения предоставляемой нашим заказчикам и партнёрам ценности, всё будет только лучше, лучше и лучше. 😉  Мы ведь не стоим на месте, постоянно идёт развитие. В том числе благодаря общению на данном портале (спасибо всем участникам!).
       
      EXIN, разумеется, списывать со счетов не следует, поскольку, во-первых, объявленное изменение произойдёт только через год. Во-вторых, у коллег весьма богатый портфель собственных продуктов.

  • Александр

    Коллеги! Доброго времени суток!

    На данный момент решили применить метрики из книги ITSM Руководство по измерению.

    Для процесса управления инцидентами и запросами на обслуживание были выбраны 2 ключевых метрики – TPI и TCR как и рекомендует книга)

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

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

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

    Можно как то избежать футбола? В книге ответа не нашел. Помогите)

  • Дмитрий

    Пожалуйста подскажите, по ситуации

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

    Насколько это соответствует практикам ITIL и здравому смыслу? Ведь сами параметры сервиса уже описаны в каталогах услуг и других документах ITSM, и в принципе процессинг это части ИТ.

  • Роман

    Добрый день.

    Подскажите алгоритм расчета времени SLA по услугам. К примеру мы знаем, что услуга состоит из 5 поддерживающих, т.е. у нас есть 5 OLA. Итоговый SLA будет путем сложения OLA1+…+ OLA5 или нужно учитывать другие факторы?

  • Андрей

    Добрый день всем! У меня с нашим проблем-менеджером возник спор, кто же все таки должен контролировать решение ИТ проблем? Он утверждает что инцидент-менеджер, он же инициатор проблемы, должен вести непрерывный контроль за решением проблемы, при необходимости "пинать" инженеров или change менеджемент, который решает проблему, так ли это? В моем понимании инцидент-менеджер безусловно является инициатором проблем, но далее, он передает это на уровень проблем-менеджмента, и в его зоне остается лишь окончательная проверка и подтверждение устранения проблемы.

  • Ольга

    Добрый день!

    В COBIT в описании атрибута возможностей 3.1 Process Definition речь идет о стандартном процессе и определенном процессе: A measure of the extent to which a standard process is maintained to support the deployment of the defined process. Не могли бы вы пояснить, что это за сущности и в чем разница? Спасибо!

  • Дмитрий

    Добрый день,

     У нас в компании  возникло жаркое обсуждение можно ли/ и как правильно повышать приоритет инциндента в ITSM tool? У каждого из заказчиков это реализовано по разному, а как у Вас?.

    Возникают следующие вопросы:

    1) В случае повышение уровня инцидента ( например с p4 на p3) , должен ли cчетчик SLA перезапускаться? ( иначе инцидент может быть просрочен  уже в момент, когда подняли приоритет)

    2) Можно ли вообще поднимать приоритет инцидента без закрытия тикета с меньшим приоритетом?  ( например на одном из проект, если нужно поднять приоритет , то старый закрывается и открывается новый с более высоким приоритетом, при этом закрытый тикет связывается  с вновь открытым )

    3) Что говорит ITIL по этому поводу? Какие лучшие практики?

     

    Заранее спасибо 

  • Анна Лобова

    Коллеги, добрый день!

    Скажите, кто-нибудь имеет опыт увязывания результатов работы конкретных сотрудников по выполнению запросов/нарядов с их премиями? Понятно, что корреляция не 100%-я, мы хотим, чтобы был коэффициент для каждой должности, кто на сколько процентов вовлечен в обработку запросов – столько процентов премии и будет зависеть от выполнения запросов… интересуе сама методика и опыт.

    Спасибо!

     

  • Арсен Юрьевич

    Добрый день, вводим в эксплуатацию отдел технической поддержки, один из вопросов, который меня беспокоит: Как "заставить" пользователей обращаться только в тех. поддержку?". Культура компании сложилась так, что долгие годы пользователи звонят понравившимся им специалистам или просто знакомым. Поделитесь опытом, кто как с эти боролся и как прививали единую точку входа.

  • Игорь

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

  • Pavel

    Столкнулся с выбором решения для CMDB. Есть известные и раскрученные поставщики по Gartner, например. Но хочется расширить "лонг-лист" и рассмотреть и другие варианты, которые не так легко гугляться. Поделитесь, пожалуйста, опытом либо теорией.  

  • Анна Лобова

    КАК КОРРЕКТНО НАСТРОИТЬ ЧАСОВЫЕ ПОЯСА В ИТСМ-системе: по Заказчику или по исполнителю работ?

    Друзья! Есть ли у кого опыт настройки в ИТСМ-системе разных часовых поясов? Дело в том, что у нашей компании география по всей россии и Центры экспертиз (рабочие группы) есьт в нескольких часовых поясах.

    Вопрос: в запросе СЛА должен тикать по часовому поясу ответственного за запрос или по часовому поясу инициатора запроса?

    У нас мы настроили таким образом, что в рамках запроса есть наряды (могут быть назначены на разные Центры экспертиз). За запрос отвечает тот ЦЭ куда направили первый наряд (альтернативы пока не придумали) с возможностью передачи ответственности за запрос.

    1) Если настраиваем регламентное время запроса по часовому поясу инициатора запроса (пользователя), то есть риск, что наряд может выполняться Центром экспертизы, живущим в другом часовом поясе и ЦЭ (центры экспертиз) будут жаловаться "нам что ночью работать?"

    2) если настроим регламентное время по часовому поясу ответственного за запрос, то непонятно как быть с нарядами. Ведь СЛА только в запросе (в нарядах его нет) и может получиться, что один наряд попадет в тот же часовой пояс, что и ответственный за запрос, а другой наряд будет выполняться другим регионом РФ и мы опять же наткнемся на вопрос "нам что ночью работать?"

    Может настроить астрономическое время?

    Коллеги, а как у вас?

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

    Спасибо.

  • Владимир

    Добрый день!

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

    1) Можно ли на всех пользователей сразу завести одну заявку в Service Deck, или необходимо заводить отдельную заявку на каждого пользователя?

    2) Что об этой ситуации говорит ITIL?

  • Динара

    Добрый день, подскажите пжт может ли владельцем процессов ITIL быть  коллегиальный орган (например Рабочая группа), а не человек, за которым закреплена данная роль?

     

    Заранее благодарю

  • Андрей

    Добрый день.

    Прочитал книгу «Руководство по измерению» – все понравилось, все по делу! Но тема раскрыта в разрезе измерения самих процессов и их производительности.

    Теперь хочется научится переводить все это в деньги. 🙂

    Нужны ответы на вопросы: «Сколько стоит один инцидент / запрос на обслуживание?», «Сколько стоит блокирующий инцидент (сбой)?», «Сколько стоят этапы работы: классификация запроса, переназначение, заполнение параметров после выполнения», «Какова средняя стоимость 1 часа работы по запросу для 1- 2- 3-линии».

    Подобные знания позволят намного эффективнее выбирать доработки и изменения для реализации. 

    Например у нас есть типовой ЗнО, и есть идеи по автоматизации его решения. Разработка обойдется в N рублей, а ожидаемая прибыль от доработки в месяц P рублей (не считая удовлетворенности пользователей). Отранжировав доработки по такой логике мы начнем делать самые рентабильные задачи в первую очередь, и заметно упростится согласование выделеного ресурса на проекты.

    В итоге вопрос: есть ли какая-то литература или опыт по финансовой оценке процессных и технологических элменетов ИТ-поддержки?

  • Ольга

    Коллеги, добрый день!

    Поделитесь, пожалуйста, какие наиболее эффективные способы получения обратной связи от пользователя вы используете.

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

    Исходные условия: не все пользователи имеют почтовый ящик; не все пользователи имеют отдельный компьютер (несколько пользователей работают с одного компьютера) и телефон.

    Используем следующие способы, каждый из которых имеет плюсы и минусы:

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

    2. Целевые опросы по тому или иному аспекту обслуживания.

    3. Обзвон пользователей с просьбой оценить качество обслуживания. Проблема – трудоемко, дорого и не слишком эффективно: пользователь отсутствует на рабочем месте, занят, не любит разговаривать по телефону и т.д.

    4. Запустили процесс управления жалобами, он пока совсем не идеален, но какие-то выводы уже можем делать на основе информации из этого процесса.

    Используете ли вы какие-то другие способы?

    Спасибо!

  • Анна Лобова

    Друзья, пожалуйста, скажите база Известных ошибок должна быть обязательно отдельной базой или можно в сущности "Проблема" (в ИТСМ-системе) просто добавить поля "Известная ошибка" и "Обходное решение"? Какие вообще вы для сущности "Известная ошибка" у себя атрибуты используете?

    Спасибо!

  • Александр

    Уважаемые коллеги!

    Вопрос следующего свойства:

    По книге "ITSM Руководство по измерению" успешно внедряем индикаторы для процессов Inc mng и rf (Service request) mng, выбрали 2 индикатора TPI и TCR, как сбалансированые.

    Вопрос в следующем: Как однозначно оценить "эффетивность сотрудника" т.к. если сотрудник 1 решил за месяц 200 обращений – у него TCR 0.78 и TPI 0.80 а второй решил 10 обращений и у него оба индикатора равны 1 (Идеальный). В описании измерений процессов не нашёл информации как сие реализовать чтоб было честно, с точки зрения сотрудника 1. 

    Свой вариант: Ввести "нормирование" количества обращений выполненых за период, но данный вариант не предусматривает другие важные задачи (Проекты, Задачи менеджера процессов…) Т.е. мы не можем однозначно сказать что сотрудника 2 не справился, т.к. у него всего 10 обращений, без анализа полной деятельности. 
    Помогите разобраться как соединить результаты по индикаторам и "общую эффективность" Буду крайне признателен если найдутся примеры реальных кейсов.
    Спасибо!

  • Екатерина

    Добрый день, коллеги! Наша компания находится на этапе внедрения процессов ITSM. В качестве первоочередных к внедрению процессов остановились на 6: управление обращениями, управление инцидентами, управление запросами на обслуживание, управление изменениями, управление конфигурациями, управление проблемами. Возник спор: в какой последовательности внедрять процессы. Я считаю, что правильнее было бы сперва смоделировать и описать регламенты всех шести процессов, а уже после этого формировать требования для разработчиков системы автоматизации, автоматизировать и обучать персонал новым правилам работы, т.к. часть изменений в системе автоматизации по одному процессу затронет и другие. Коллеги придерживаются мнения, что внедрять каждый из процессов нужно последовательно. Подскажите, есть ли какие-то жесткие требования к последовательности внедрения процессов? Можно ли нарушить эти требования, исходя из соображений оптимизации трудозатрат внедренцев, разработчиков систем автоматизации и персонала?

  • Антон Герасимов

    Приветствую коллеги! Возникла следующая дилемма. Есть три способа подачи заявок в ServiceDesk: 1. Веб-портал (где пользователь сам выбирает сервис ИТ). 2. Письмо по электронной почте (тогда все заявки сваливаются на первую линию и их категоризует один из сотрудников первой линии). 3. По телефону (только в случае невозможности первых двух способов.

    Самый эффективный способ с точки зрения руководителя ServiceDesk – первый. В этом случае, во-первых, значительная работа по категоризации заявки проводится самим пользователем (он сам выбирает тип заявки (инцидент, ЗНО, ЗНИ) и сервис ИТ). Во-вторых, по некоторым сервисам (которые первая линия всегда эскалирует на вторые) заявка сразу попадает на вторые линии, специалисты которых выставляют лишь срочность и влияние. В случае с заявкой по электронной почте, сначала она попадает в пул новых, если за 15 минут ее никто не возьмет (а это происходит в 90% случаев), то она назначается на одного из сотрудников первой линии. После чего еще в среднем 15 минут он ее категоризует. То есть в среднем заявка с портала решается на полчаса быстрее по вышеназванным причинам.

    Отсюда задача мотивировать пользователей делать заявку с портала, а не по почте. Один из вариантов мотивации – объяснять, что с портала заявка быстрее решается (на 5 минут дольше формировать заявку самим пользователем, зато на полчаса быстрее решение).

    Вопросы в следующем:

    1. Как это соотносится с методологиями ITIL?

    2. Целесообразно ли регулировать это на уровне SLA? Мол, заявка с портала идет по одним SLA (более жестким). С одной стороны, вроде как это криво: пользователей не должно волновать откуда заявка, IT служба должна максимально быстро ее решать. С другой стороны, объективно выходит, что заявка с Портала решается быстрее за счет небольшой (не больше 5 минут) допнагрузки на пользователя, небольшой (1 минута) нагрузки на вторую линию (приоретизация), и существенного ускорения (полчаса) прохода первой линии.

    Коллеги, Ваше мнение?

  • Антон Герасимов

    Коллеги, добрый день! Прочитал много материалов, касающихся Problem Management. Совсем не прочувствовал идею, что Управлению проблемами сложно внедрять и до него нужно "дорасти". Возьмем на примере. Звонит пользователь, и говорит, что не может на компьютер зайти – заблокирована учетная запись. Причем утверждает, что это происходит каждый день. Проверяю по тикетам – так и есть. Каждый день мой сотрудник первой линии успешно решает данный инцидент. То есть налицо наличие проблемы. Но Problem Management не выстроен. Я хочу, чтобы ITSM система мне позволила на основе данного инцидента создать проблему, которую перевести на вторую линию, к которой можно приклеить прошлые такие же инциденты. Сейчас это решается созданием инцидента на вторую линию. Но хотелось бы разграничить и в статистику строить по инцидентам и проблемам отдельно. Как это проще всего сделать? В окне работы с инцидентом добавляем новую кнопку "Создать проблему". Создается новый тикет, с типом "Проблема". В первом приближении, в ITSM системе проблема будет отличаться от инцидента только типом тикета. То есть мне, по-сути, надо лишь добавить тип тикета "Проблема", которая скрыта пользователям, но открыта агентам. Проблемы точно также решаются специалистами второй линии. Единственное явное отличие – их не надо как инциденты закрывать пользователям. В чем сложности и ущербности такого PM?

  • Андрей Вишняков

    Как мотивировать сотрудников фиксировать свои изменения в рамках процесса Change Management?

    Периодически выявляются случаи проведения изменений в ИТ инфраструктуре, проведенных за рамками соотвествующего процесса. При этом сотрудники в свое оправдание дают пояснение вида: не оформил RFC потому что: это тестовая среда/ это по SR от заказчика/ работы в рамках стандартного функционала услуги/ конфигурация самой системы не затрагивается и тд

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

    Как сформулировать наиболее доходчиво именно простому админу, зачем ему необходимо заниматься лишней бюрократией (оформлять RFC, дорабатывать план, согласовывать с CAB, etc..) ?

    Просьба  к колегам поделиться опытом, вариант кнута не предлагать) а если пряника, то просьба поподробнее))

    Спасибо!

     

     

     

  • Андрей

    Добрый день! Возник следующий вопрос. Как правильно рассчитывается норматив по количеству обращений за одну рабочую смену на 1FTE первой линии? И может ли вообще такой норматив быть рассчитан, и главное применим ли к 1 линии? Сейчас у нас эта цифра есть, но правильно ли она рассчитана, хотел бы разобраться с вашей помощью.

  • Ольга

    Здравствуйте!
    Помогите, пожалуйста, разобраться с понятием продукта в контексте синхронизации двух концепций: гибкой разработки ПО и ITSM.

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

    С определением ИТ-услуги все понятно (ITIL нам в помощь), а с продуктом сложнее. Часто определение продукта формулируется не напрямую, а через описание его свойств (или их отсутствия), в том числе по сравнению с услугой. Например, “продукт является осязаемым и может **** сейчас или позже, в то время как услуга неосязаема и не может быть получена заблаговременно”. Troy DuMoulin как-то цитировал в своем блоге John Arther Ricketts, автора книги Reaching The Goal. Тот считает, что многие товары являются сочетанием продуктов и услуг: So pure goods (products) and pure services are just end points on a continuum of possibilities. Но хотелось бы четких определений этих конечных точек 🙂

    Спасибо!

  • Дмитрий

    Всех приветствую

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

    Имеется:
    Техподдержка состоящая из 20 сотрудников. Обращения поступают в основном по телефону. Помимо обработки таких обращений сотрудники выполняют текущие задачи по установке оборудования, программного обеспечения, выезды на объекты компании и т.п. Техподдержка работает 14 часов/7 дней в неделю/365 дней в году.

  • Арсен Юрьевич

    Доброго времени суток, хочу подготовиться и сдать экзамен OSA этой весной. Готовлюсь по официальным книгам ITIL v.3, 2011, есть сертификат ITIL Foundation и опыт работы в поддержке 3 года. Очень хочется потренироваться в решении сценариев с экзамена. Видел и прорешал всего один пример экзамена Sample Paper 1, version 6.1. Можно где-нибудь порешать тестовые примеры из OSA? Возможно будут ещё какие-нибудь рекомендации от тех кто уже сдавал OSA. Спасибо.

  • Сергей Семикин

    Коллеги, всех приветствую.

    Хотел поднять тему внедрения управления услугами на уровне предприятия (Enterprise Service Management). На тему натолкнула статья Стюарта Рейнса Incident Management Isn’t Just For IT (оригинал https://optimalservicemanagement.com/blog/incident-management-isnt-just-for-it, перевод https://habrahabr.ru/post/347488/).

    Кому-нибудь приходилось участвовать в таком преобразовании процессов? С какими трудностями сталкивались? Известны случаи, когда инициатором таких проектов был именно ИТ и ИТ оставалось рулить процессами? На сколько успешно это было?

  • Maksym

    Коллеги, приветствую.

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

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

    Поделитесь своими методами

  • Дарья

    Добрый день! Коллеги, нужна ваша помощь в следующей ситуации. Я совсем недавно стала менеджером управления конфигурациями. В компании учет ведется по услугам, ПО, серверам и некоторой частью ПВТ и Периферии. Издала распоряжения, в которых прописано о том, что информация обязательно необходимо фиксировать, что она должна быть актуальной и достоверной т.п. И сейчас с помощью выгрузок и отчетности я контролирую ввод информации в CMDB. Но столкнулась я со следующей проблемой – как контролировать именно достоверность введенной информации? Я могу “припугнуть”, “побить палкой” за то, что информация не была введена вовремя, хоть это и не на всех работает. Но как я могу проверить, что например, версия ПО или номер ячейки, в которой лежит сервер – введены корректно? Во-первых, я не владею всеми тонкостями ИТ в каждой ее области да и не должна, во-вторых, я не смогу физически каждый месяц ходить ногами и проверять своими руками каждую КЕ. Остается только верить на слово администраторам КЕ и есть те, которым верить можно, но попадаются и те, которые вводят информацию только для того, чтобы от них отстали – заполнены все обязательные поля в карточке КЕ и ладно.

  • Никита

    Коллеги, добрый день.
    Сразу извиняюсь за сумбурность изложения.)))
    Я являюсь юным менеджером процесса SLM (3 месяца). Так совпало, что с моим приходом на должность, в нашей организации (крупный региональный банк) был затеян реинжиниринг этого процесса.
    По причине изменения подхода, формата документа и т.д. многие SLA пересматриваются. И я столкнулся с вопросом для ответа, на который хотел бы заручиться мнением больших экспертов. Ранее в банке существовало 2 типа SLA: SLA по бизнес-процессу (кредитование ФЛ, депозиты ЮЛ и т.д.) и SLA по “каналам продаж” (банкоматы, интернет-банки и т.д.).
    И вот придя в одно из подразделений, у которого много проблем с ИТ (да и сам заказчик проблемный) понял, что бизнес-процесса как такого у заказчика нет, это операционное подразделение, которое выполняет «куски» нескольких бизнес-процессов. На мой взгляд, в этой ситуации следует найти владельцев этих БП (которых, к сожалению, нет, но это уже другая проблема) и заключать SLA с ними на весь БП. Но заказчик считает, что SLA должен заключаться только с ним, в старом варианте. Есть идея ввести 3 тип SLA, условно на «отдел/подразделение», но тогда в этом SLA практически не будет критичности (она определяется от влияния на банк), т.к. вся критичность уйдет в SLA по БП, и он вряд ли на это согласится.
    Собственно хочется попросить поделиться опытом разрешения подобных конфликтов интересов. Верно ли, мое предположение и надо продавливать его через верха или прав заказчик, а может быть есть другой вариант разрешения?

  • Арсен Юрьевич

    Уважаемые коллеги. У меня в подчинении две линии технической поддержки: первая линия — диспетчеры тех. поддержки (принимают обращения, решают элементарные обращения/инциденты, сложные обращения/инциденты эскалируют на вторую линию), вторая линия — консультанты тех. поддержки (решают сложные обращения/инциденты, эскалируют на третью линию обращения/инциденты, если нет прав доступа или не хватает компетенций). Классика. На второй линии два консультанта, необходимо их по разному загружать обращениями — одному давать 70% всего потока запросов, второму 30%, так как второй занимается ещё и документацией. В своей ITSM системе мы вывели для первой линии виджет, который показывает загруженность консультантов второй линии, т.е. диспетчер видит сколько обращений в работе и у кого и фактически распределением обращений занимается диспетчер первой линии. Слышал про практику, когда распределение занимается менеджер процессов тех. поддержки, так как диспетчер не всегда компетентен в распределении обращений. Покритикуйте мой кейс, оставлять этот функционал за первой линией или вверить менеджеру процессов? Расскажите как это устроено у вас.

  • Арсен Юрьевич

    Добрый день, коллеги! Подскажите как соблюдать SLA в условиях ожидания ответа от клиента/бизнеса. Например, определили опытным путем SLA по сервису “Настройка бухгалтерской базы” в 24 рабочих часа. Т. е. все обращения по этому сервису должны решатся в этот согласованный срок. В поддержку поступает обращение, классифицируется по этому сервису и в ходе решения обращения выясняется, что требуется настройка, затрагивающая учетную политику. Это требует согласования главного бухгалтера. Гл. бухгалтеру отправляется запрос на согласование, бухгалтер рассматривает согласование, например, в течение 72 или более часов. Что делать с обращением в таком случае? Ведь фактически срок SLA будет нарушен. Сейчас мы переводим такие обращения в статус “Ожидает ответа” и срок решения ставится на паузу. Но это плохая практика, так как под этот статус можно подогнать многие обращения: клиент не решил, клиент ждет согласования, клиент в отпуске, клиент заболел и т.д.
    Другой пример, определили срок по сервису “Подключение камер видеонаблюдения” – 72 рабочих часа. Поступает обращение по данному сервису, в ходе решения выясняется, что камеры отсутствуют на складе, а поставщик сможет сделать поставку только через месяц, мы снова ставим обращение в статус “Ожидает ответа”. Это плохо, потому что мы искусственно ставим на паузу время разрешения обращений, мы накапливаем огромный пул таких обращений, растет долг перед клиентами.
    Примеров много, практически по каждому сервису есть свои особенности в части ожиданий от ответов клиентов/бизнеса. Возможно, есть какие-нибудь более изящные решения по этой проблеме?

  • Максим

    Добрый день

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

    1. Установление контроля над основными элементами ИТ инфраструктуры, определение связей как между частями ИТ инфраструктуры, так и между ними и основными бизнес сервисами для проведения критичных для бизнеса изменений
    2. Лицензионный контроль ПО
    3. Интеграция с системами мониторинга

    Смотрел в сторону iTop. Рассматривал решения на базе 1С, слишком громоздко. Полный функционал HelpDesk (serviceDesk) не нужен, обработка заявок и запросов пользователей уже реализована в другой системе.

  • Сергей

    Хотел бы задать вопрос в студию о наболевшем.
    Ситуация следующая: рабочие группы обрабатывают заявки только через Таски (рабочие задания), ничего другого они не видят, хотя практическая возможность из Таска заглянуть в Инцидент или ЗнО\ЗнИ присутствует.
    Заказчику мы естественно “продаём” Инциденты и Запросы.

    Сейчас мне настойчиво “предлагают” отойти от схемы указания в Инц\ЗнО\ЗнИ группы поддержки (поле Группа назначения), потому как может быть несколько одновременно выполняемых Тасков (или ещё пор каким то причинам) да и сами группы работают только с Тасками.

    Т.е. увидеть в списке\перечне Инцидентов (например) кто сейчас за него отвечает возможности не будет и это усложнит подготовку отчётов для заказчика (прописывать логику что из какого таска должно попасть в отчёт Заказчика по Инц\ЗнО\ЗнИ – малоприятного).

    Вопроса два:
    – что думает об этом, снятие (“де-факто”) ответственности за исполнение Инц\ЗнО\ЗнИ с групп поддержки, уважаемое сообщество
    – есть ли отработанные и практические советы как в этом случае эффективно управлять процессами и контролировать обработку Инц\ЗнО\ЗнИ сервис-менеджеру.

  • Вячеслав Бельков

    Здравствуйте Уважаемые, доблестная команда Cleverics,
    как и всегда, в данном разделе, есть вопрос (с кратенькой преамбулой):
    я устроился на новую работу, в достаточно большую компанию, может быть не такую максимально зрелую с точки зрения процессов, но с прекрасным коллективом – очень молодым, открытым к общению, адекватными людьми с горящими от интереса глазами, впитывающими новое как губки… О чем это я… – да, так вот!!! Внимание вопрос.
    У вас на портале Cleverics есть архив вебинаров по очень полезным и интересным темам, с которыми я бы очень хотел познакомить и сутью из которых хотел бы заразить своих коллег, моих сотрудников ИТ службы. Материала у вас там накоплено уже так много, вебинары выходили длительное время – с давних времен, еще когда я сам учился азам, до текущих дней, сложность их разная, темы различные. Начинающему – не разобраться…
    Вот было бы супер удобно и полезно, если была бы возможность их структурировать как “в букваре, от А до Я” – начать с первого (не по ДАТЕ выпуска, а по восприятию, по теме/по сложности/по смыслу) и так и идти по очереди к следующим, усложняя и материал и темы, а?
    То есть, например, что я имею в виду, я ребятам даю ссылку на архив, говорю- сегодня смотрим/изучаем раздел такой-то, шифр такой-то, где сначала они возьмут какой-то материал по базовым основополагающим вопросам из ITIL. Далее, ознакомившись с терминологией/понятиями- перейдут уже к сервис-дескам, конфигурациям, CMDB, SLA и SLM. Следующим шагом, кто хоть что-то поймет, перейдут уже к ITSM-ам и кобитам, девопсам, стандартам и управлениям проектов… Ну или как-то по-другому, Вам профессионалам видней… 😉
    Таким образом, я смогу и подтягивать коллектив к процессным знаниям (без своего участия), повышать из зрелость и как специалистов и как просто людей, для обычной жизни. ТАК еще и быть уверенным, что читают/слушают они самый правильный материал, составленный лучшими гуру современности в этих вопросах, а подающих надежды своих подчиненных- посылать к Вам на обучение… 🙂
    Спасибо. Вячеслав

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

      Слава, привет!
      В архиве вебинаров есть фильтр сверху, можно отобрать по уровню сложности. Мы делим вебинары на три уровня: простой, для подготовленных, для экспертов. Уже можно выбрать с чего начинать.
      А второй полезный фильтр – по темам. Мы относим каждый вебинар к нескольким темам, чтобы можно было из 100+ выбрать те, которые полезнее всего именно сейчас.
      Порядок изучения я бы рекомендовать не стал, так как его сложно сделать общим для всех. Начальная точка у каждого своя, и интересные области свои. Напротив, мы стараемся охватить больше: и про ITIL, и про COBIT, и про PRINCE2. Теперь и до DevOps добрались 🙂

  • Aleksandr

    Какие 3и проблемы часто встречаются в международных компаниях FMCS по Вашему опыту использующие подход ITSM

  • Sinan Aliyev

    Такой вопрос:
    В книге ITIL4 Foundation нет раскрытия аббревиатуры ITIL – IT Infrastructure Library? Если ITIL это эволюция IT (best practice), призванная создать гайд для IT(SM), то почему первые две буквы IT(IL) теперь выглядят так ущербно? Или ITIL теперь уже не “библиотека” лучших практик?

  • Альфия

    Доброго дня! посмотрела видео с запуска ITIL 4 – спасибо!
    в списке практик искала Event management – не нашла, но удовлетворилась пояснением, что практики могут содержать несколько процессов и, вероятнее всего, event management не будет потерян и забыт.
    Затем решила проверить, а сдам ли я ITIL 4 foundation и скачала Sample paper с вопросами. На третьем вопросе возникла коллизия: “Which is the purpose of the ‘monitoring and event management’ practice?” Да, на него можно ответить, зная ITIL v3, но… ведь практики-то такой нет формально. Или я чего-то недопоняла, пожалуйста, поясните.

  • Денис

    Вопрос про конвеер заявок.
    Допустим поступает 5 заявок на 4х сотрудников. 4 раздаются автоматом, а как бысть с 5й?
    Варианты:
    1) Заявка висит в очереди, пока кто-то не освободится и не закроет свою, а после этого назначается на первого освободившегося.
    2) 5 Заявка назначается сотруднику 1, 6-я – сотруднику 2. В итоге сотрудники уже имеют в работе по 2 заявки одновременно. Но тогда появляется ситуация, что KPI посчитан по одной заявке, а время идёт сразу по двум (т.е. получаем что либо сотрудник должен в два раза быстрее теперь справиться, либо KPI должен быть в 2 или в 3-4 раза больше, чем необходимо).
    Как на практике применяется этот момент? Спасибо!

  • Денис

    Хотя вот нашел часть ответов здесь, https://realitsm.ru/2013/02/pickup_time_as_kpi/
    Спасибо!

  • Екатерина

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

  • Алексей Рожков

    Добрый день!

    Какие существуют рекомендации или лучшие практики по принятию нового сервиса на поддержку службой Service Desk. Положим, в рамках внутреннего проекта происходит внедрение транспортно-логистической системы. Поддержка системы после сдачи в эксплуатацию предполагается имеющимся штатом службы Service Desk. Какие действия должны быть предприняты со стороны ServiceDesk для того чтобы на входе получить минимум проблем?

  • Sinan Aliyev

    Добрый День,
    А с какими навыками, умениями, знаниями должны уйти слушатели с курса ITIL4 Foundation? Какие были ожидания до начала курса и результат после завершения курса? Вопрос как к тренерам и консультантам, так и к слушателям прошедший этот курс.

  • Кирилл

    Уважаемые коллеги,
    Приветствую!

    Буду крайне признателен за публикацию данного вопроса.
    Внедрение CMDB – тема уже изъезженная, но практической информации крайне мало.
    Помогите, пожалуйста, не наступить на “те самые” грабли.

    Мы понимаем, где мы сейчас – осуществлена оценка текущего состояния. ИТ и заказчики видят и понимают проблематику, ограничивающую предоставление услуг с более высоким качеством из-за отсутствия CMDB.

    Мы знаем, что мы хотим – были собраны бизнес-потребности, при сборе отталкивались в первую очередь от задач, которые необходимо решить.

    Задачи:
    1. Выстроить процесс управления ИТ-активами и конфигурациями (данные об активах содержаться в разных источниках и постоянно устаревают, пользовательское и серверное оборудование регулярно не обновляется, зачастую не удовлетворяет требованиям)
    2. Онлайн доступ к актуальной информации по ИТ-активам и конфигурациям в web-интерфейсе:
    отчет по физическому местонахождению ИТ-активов
    отчет по надежности ИТ-активов!
    отчет по модернизации
    отчет по лицензиям
    отчет по устареванию версий критичного ПО
    3. Выстроить процесс управления лицензиями
    4. Внедрить практику РСМ по критичным сервисам вплоть до конечных потребителей (отсутствуют знания об архитектуре услуг, нет планов непрерывности, доступности крит. систем, нет устойчивой основы для управления инцидентами, проблемами, изменениями и релизами)

    Цели:
    1. Контроль жизненного цикла всех ИТ-активов и конфигураций
    2. Получение точной информации о конфигурациях и документации для поддержки всех прочих процессов управления сервисом
    3. Построение устойчивой основы для управления инцидентами, проблемами, изменениями и релизами

    Главный вопрос – как нам это сделать?

    Как оценить/просчитать бюджет проекта по внедрению? (нафига козе баян?)
    Какие очевидные и не очевидные риски?
    Какое выбрать ПО?
    Как разработать структуру CMDB?
    Какой примерный план по внедрению этого инструмента и изменению сервисных процессов?

    СПАСИБО!

  • Илья

    Мне не пришла аудио книга, обещанная при регистрации!
    Что делать?
    Очень хочу послушать

    • Илья

      Вопрос снят
      Ссылка пришла на почту
      Спасибо!

  • Никита

    Приветствую коллеги.
    Волею судеб из корпоративного ИТ-сектора попал в государственный.
    Многое в новинку, многое в диковинку, пока втягиваюсь. Однако тяжелое ITSM прошлое не дает сидеть на месте. Куда не глянь, вижу область для улучшения и так и хочется засунуть свои ручонки для нанесения всеобщего блага))) С другой стороны, объемы работ и отсутствие опыта преобразований в государственном ИТ слегка пугает.
    Отсюда родился вопрос и тема для обсуждения.
    Знаете ли вы успешные (и не очень) кейсы внедрения ITSM инициатив в отечественном ИТ гос. сектора? Может есть личный опыт участия, и вы сможете поделиться на какие грабли наступали. Вопрос конечно слишком общий и абстрактный, но все же, хочется узнать какие есть взгляды.

  • Denis

    Вопрос по приоритетам. У сотрудника второй линии есть три заявки в работе, над одной он работает, по двум другим идёт время и эти заявки с приоритетами “срочный”и “средний”. Заявки поступили в разное время, закончив первую, сотрудник по идее должен перейти к срочной. Но на практике заявка с приоритетом средний (пока сотрудник работал над заявкой номер 1), уже почти исчерпала время решения, так как поступила гораздо раньше средней. и остались считанные минуты до нарушения SLA. Сотруднику, чтобы не потерять KPI, нужно быстро обработать среднюю, а срочный вопрос на потом.
    Получается конфликт интересов сотрудника и заказчика. Ведь хотелось, что бы срочные вопросы обрабатывались в первую очередь. Как этого добиться?

  • Олег

    Добрый день.
    Как следует поступать со “старыми” инцидентами?
    Пример 1.
    Инцидент не закрывается уже длительное время, например, месяц. Причина – отсутствие ресурсов/времени у специалистов. Следует ли открывать проблему и закрывать после этого инцидент?
    Пример 2.
    Внешний инцидент не закрывается уже длительное время, например, месяц. Причина – вендор не предоставляет исправление. Следует ли открывать проблему и закрывать после этого инцидент?

  • Антон

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

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

    Тк есть инциденты с одинаковой проблемой, регистрируется проблема. Которая привязывается к запросу на вендора. Насколько это правильно, с точки зрения организации процесса?

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

    Имеет ли смысл выделять главный инцидент, к которому привязываются инциденты с такой жен проблемой? Главный инцидент привязывать к проблеме (или к запросу на вендора)?

    Спасибо

  • Алексей+

    Здравствуйте!
    ИТ-архитектура является частью CMDB или наоборот ?
    Спасибо!

  • Denis

    Добрый день! Какой критерий может проактивно показать, что группа перестает справляться с поступающим потоком обращений? Как у вас налажен этот процесс? Хотелось бы выявлять перегрузку до того, как будут сорваны договорные сроки, настроить какой-то “красный сигнал”, что вот на данный момент дела начинают идти плохо.

    В магазине это растущая очередь в кассе до определенной величины, сигнал того, что нужно подключать еще кассы. А как на практике используете вы, какие индикаторы? (возможно размер очереди или еще какие-то параметры).

    Спасибо!

  • Ульяна Сусак

    Добрый день!

    Безуспешно ищу на форуме тему учета кратности работ при расчете срока оказания услуги (SLA).
    Кейс следующий:
    Наша организация оказывает ряд услуг, работы по которым могут быть множественными. Например, руководитель отдела делает заявку, что необходимо установить ПО на 10 ПК его сотрудников. Или от клиента поступила заявка на изготовление 5 ЭЦП. Диспетчер принимает заявки такого типа как одно обращение и указывает кратность работ 10 или 5. Инженер выполняя работы по обращению может учесть эту кратность при фиксации трудозатрат, с учетом того что норма на одну работу заранее четко определена. Исходя из описанного кейса возникает несколько вопросов:
    1. Логично предположить, что кратность работ должна влиять не только на трудозатраты, но и на срок предоставления услуги (если это заранее оговорено в договоре с клиентом). На каком этапе должно учитываться это влияние, с учетом того, что кратность может увеличиться в процессе выполнения работ? Например, понадобилось настроить не 10 ПК, а 12.
    2. Вытекает из первого вопроса. Если мы будем удлинять срок заявки в зависимости от кратности, клиент просто будет подавать не одну заявку на 5 ПК, а 5 заявок на каждый ПК. Срок у таких заявок стандартный, кто и как их будет выполнять клиента не волнует, мы должны уложиться в SLA по каждой заявке. Насколько правильно предположение из первого вопроса?
    2. Как и кто должен фиксировать наряды по обращением с кратными работами? Не очень правильно заводить 10 нарядов на 10 ЭЦП. Заводить одно задание с кратностью 10, тоже не совсем верно, так как первые 5 ЭЦП может выпускать один сотрудник, а вторые 5 – другой. Диспетчер при назначении нарядов по заявке знает только количество ЭЦП и рабочую группу, оказывающую услугу по их выпуску. Кто именно будет выполнять работы определит координатор группы, уже получив заявку. И он же, по идее, должен создать нужные наряды на нужных сотрудников?

  • Ульяна

    Добрый день!

    Интересна тема переклассификации обращения после начала выполнения работ по нему. Обращение классифицируется диспетчером на первой линии, он вносит услугу, определяющую SLA. Заявителю отправляется уведомление о регистрации обращения с указанием услуги и срока решения заявки согласно SLA этой услуги.

    У нас необходимость переклассификации обращения в плане изменения изначально определенной услуги, возникает в следующих случаях:

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

    2. После эскалации работ по обращению одной рабочей группой на другую выяснилось, что вторая рабочая группа будет оказывать свою услугу (за которую она ответственна). При этом срок оказания их услуги отличается от срока определенной изначально услуги. Например, заявка поступила на неработоспособность ПО 1С:Бухгалтерия (срок решения: 8 ч.), а сотрудник отдела 1С выяснил, что не работает сервер, и эскалировал заявку на инфраструктурщиков. Они выяснили, что по тех. причинам сервер периодически недоступен и требуется диагностика и восстановление его постоянной работоспособности (16ч.)
    При этом заявитель изначально был оповещен, что услуга по его обращению такая-то, срок такой-то. А мы эти параметры в процессе работы хотим изменить.

    Как обычно поступают в вышеописанных случаях: инженер сигнализирует диспетчеру, что необходимо изменить услугу, диспетчер изменяет услугу обращения и заявитель уведомляется об этом постфактум? Или изменение услуги согласовывается с заявителем и у него есть возможность отставить услугу и срок прежними?

  • Антон

    Здравствуйте!
    Процесс управления проблемами
    1. На основании обращейни пользователей зарегистрирована проблема:
    определен способ обходного решения;
    Дупустимо ли в инциденте устанавливать связь с проблемой (те записью в проблем трекере) при закрытии инцидента путем обходного решения? пердполагается, что это будет выполнять специалист 2-3 ЛТП

    2. Для устранения корневой причины – требуется доработка (например ошибка при формировании требований, не является багом). В качестве решения гистрация RFC. В каком случае проблема может быть закрыта: реализация и проверка заказанной доработки или же достаточно согласование заказанной доработки?

  • Анон

    Вопрос по процессу управлени проблемами.
    В качестве решения возможны:
    1 изменение настроек компонетов системы
    2 и доработка (те реализация доп функуций, которые не были в ТЗ)

    1 и 2 относятся к процессу управления изменениями? или это разные процессы, какие?

  • Артем

    Добрый день. Вопрос наверное не новый и проблема общая. Поступает куча запросов неправильно зарегистрированных пользователем, неправильная привязка сервиса, типа запроса и т.п. Вопрос в следующем, насколько глубоко меню регистрации запроса должно быть категоризировано. Грубо говоря первая крайность – меню совсем не полей выбора привязки к сервису, к типу и т.д., пользователь просто описывает проблему своими словами, а далее все привязки делает специалист СТП при регистрации запроса. Вторая крайность – меню содержит кучу зависимых полей выбора, Сервис – Вид обращения- Тип запроса и т.д., в которых пользователь обычно путается и регистрирует запрос не верно. Хотелось бы знать есть ли какая то методология по определению дружелюбности меню(интерфейса) регистрации запроса со стороны пользователя. Ну или у кого то есть опыт в решении данной проблемы. Заранее спасибо.

  • Ульяна

    Добрый день!

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

    Насколько правильно давать инженерам такую возможность? Может у кого-то был подобный опыт?

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

  • Валерий

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

    P.S. ввод ограничений в эксель не помогает, зачастую все просто удаляют твой файл и кидают новый или их отключают, в интернете ничего похожего не удалось найти.

  • Алексей+

    Здравствуйте!
    Роман Журавлёв в статье “Главное про ITIL 4” https://www.osp.ru/os/2019/02/13054948 “…отнес к важным преимуществам то, что ITIL 4 опирается на такую научную дисциплину, как service science, предмет которой — описание цельной таксономии продуктов, сервисов, ценности, сервисных операций. ITIL 4 берет ее за основу, что делает новую версию более корректной с точки зрения описания мира управления сервисами. ”
    Просьба подробнее остановиться на этом.
    Спасибо!

  • Евгения Мазина

    Здравствуйте!

    Довольно много информации об обязанностях менеджера процесса, а какими полномочиями/правами он должен быть наделен, чтобы эффективно исполнять свои обязанности?

    Буду очень признательна за обмен мнениями по этой теме и примеры из реальной жизни.

    Всем хорошего дня!

  • denis

    Как вы относитесь к интерактивным чатам на сайтах на первой странице?

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

    Ну, ок, открываешь – там “чем могу помочь”? Блин, я не знаю чем, я не просил ничего… ну… расскажите зачем нужен этот чат. В ответ тебе пишут “этот чат нужен тем, кто хотел бы задать вопрос”. Ты в ответ думаешь – а я что задал. не вопрос разве? Озвучиваешь – тебе в ответ “для тех, у кого появятся вопросы по тематике сайта”. Хм, ну ладно, мне уже показался ответ невежливый, но еще к тому у меня не было вопросов по тематике сайта, а чат зачем-то мне сигналил цифрой “1 непрочитанное сообщение”. Это такие трюки, как 24.99, бесят страшно. Вот думал что это не тру практики. Может только меня это все злит и раздражает? А как вы относитесь к подобным чатам?

    • denis

      И вишенка на торте – заходишь вечером, бздынь – у вас сообщение на сайте. Ок, открываешь – “извините, все операторы заняты”. Эпикфейл.

      А еще есть техника, которая мне кажется из той же категории, это когда тебе звонят, ты снимаешь трубку, а там играет музыка и мол все операторы заняты, ожидайте. Офигенный подход 🙂

  • Павел

    Добрый день!

    Кейс с организацией on-call дежурств для L3 команд. В IT департаменте организации сложилось так, что в L3 командах, которые отвечают за критичные для компании сервисы (сетевая инфраструктура, серверное оборудование, системы версионирования и т.д.) работают по 2 человека в каждой команде (сетевые админы, инфраструктурные админы, атлассиан админы и др.). В обычное рабочее время (8 на 5) идаже с учетом отпусков и больничных этой численности хватает для решения задач.
    Но есть необходимость организовать on-call дежурства 24 на 7 по обработке инцидентов по некоторым самым критичным сервисам. Процесс выглядит так что от системы мониторинга поступают алерты, поступает звонок в L1, далее L2 при необходимости, далее L3 тоже при необходимости. При этом на всех уровнях – это именно дежурство по телефону (ответить на звонок), то есть это не полноценная работа 24 на 7.
    С L1 и L2 командами в этом плане все ок, у них численность побольше, но с L3 – есть вопросы, т.к. сотруднику придется пол месяца условно быть в on-call, хоть инциденты случаются очень редко, тем не менее это все-равно накладывает какие-то ограничения для сотрудника и они сопротивляются такому подходу. Найм в команды L3 сотрудников рассматривается, но пока очень спорный, т.к. тогда не хватает загрузки для дорогих специалистов в обычное время. Также рассматриваем возможность доп мотивации сотрудников за on-call дежурства в различных видах.
    Думаю это не очень уникальный кейс и буду признателен за то, что набросаете варианты решения по нему.

  • Сергей

    Коллеги, здравствуйте.

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

    Спасибо!

  • Konstantin

    Возник такой вопрос – периодически приходят алерты с серверов об ошибке память. Теория говорит что есть риск внезапной перезагрузки сервера в период от 1 часа до пары недель. На практике сервер с такой ошибкой живет в среднем 1 неделю до ребута. Решение – миграция всех виртуалок (от 10 до 80) на другой кластер и замена модуля. Мнение как действовать разделилось:
    1. Это P1 инцидент, делаем emergency change, немедленная миграция, несмотря на бизнес часы и риск сбоя виртуалки при миграции.
    2. Это P2, делаем обычный change и выносим на CAB, у нас есть время все спланировать и мигрировать в течении 4-5 дней.
    3. Это P3, используем модель изменения в которой CAB ждать не надо, в изменении минимум согласователей из экспертов, выполняется в тот же день после бизнес часов и после уведомления владельцев виртуалок.
    Кто прав?

  • Павел

    Добрый день, вопрос про управление конфигруациями, CMDB.
    У нас в ИТ департаменте работает CMDB, внедрена система, ведется учет различных нужных нам CI, есть минимальный доступ для всех сотрудников компании, чтобы они могли смотреть свое оборудование и некоторую другую информацию.

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

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

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

Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.