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

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

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

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

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

 

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







Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

Комментарии и мнения

  1. Сергей

    Хотелось бы обсудить следующую задачу:

    Пусть мы имеем систему, которую используют 20 предприятий, общее количество пользователей 500, пусть на одном из предприятий 40 пользователей. Пусть система обслуживается с 9 до 18, время реакции 1 час, время закрытия типовой заявки на обслуживание 4 часа.

    Вопросы:

    1 какой инфориации не хватает, чтобы можно было рассчитать количество единиц службы поддержки (КЕСП)

    2. Как изменится КЕСП если указанное предприятие попросит уменьшить время реакции до 0,5 часа

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

    Спасибо.

  2. Марина

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

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

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

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

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

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

    Инцидентом низкий бал на экзамене.

    Решением инцидента является апелляция, результатов экзамена.

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

    Структурным решением является переиздание книг.

    Вопросы:

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

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

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

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

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

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

  4. Ritil ITинович

    Приветствую

    На этом ресурсе много разной информации: обсуждений теорий и стандартов, небольших фрагментов проектов. Но полных реальных realitsm проектов здесь не нашел. Прочему бы не выложить несколько хорошо документированных проектов по ITSM, мониторингу, обсудить (экспертизу, так сказать, общественную), выбрать типовые решения, показать в них как теория сочетается с практикой и т.п. Хорошо бы и ценник показать, т.е. "что по чём». Вроде бы это должно входить в понятие: «realitsm». «Лучше один раз увидеть «realitsm» в реальных проектах, чем сто раз послушать». Уверен – эффект был бы куда выше.

    Вообще, как правильно то документацию оформлять по itsm – проекту? Какова структура продукта «realitsm»?

    Идею открытой библиотеки проектов (Ritil), в том числе и в itsm области, популяризирую на ritil.blogspot.com/2012/04/ritil.html

    Какие Ваши мнения на сей счет?

    С уважением,

    Ritil ITинович

    skeptic.ru@gmail.com

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

    Работаем с системой построенной по третьему ITIL (BMC Remedy — не сочтите за рекламу).

    В третьем ITILе по которому построена наша Remedy, обращения, инциденты, изменения разнесены по разным сущностям.

    Мы говорим своим специалистам: закончил работу с Инцидентом залезай и бери новый (в зависимости от приоритета и крайнего срока).

    Однако в нашей системе (да и презенташку MS видел – там та же проблема существует) для просмотра разных сущностей – разные «вьюшки».

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

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

  6. Alexander Peshkov

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

    Если первое, все понятно — можно установить пороги и разделять.

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

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

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

  7. Денис

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

    Сейчас наша компания стоит перед выбор программного обеспечения для управления инцидентами (service desk).

    Приоритетные задачи:

    1. учёт рабочего времени сотрудников.

    2. складской учёт

    3. оценка работы со стороны клиента.

    4. учёт выручки мастеров.

    5. Трудозатраты.

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

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

  8. Dmitriy

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

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

  9. Konstantin G

    Здравствуйте, коллеги.

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

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

    Зравствуйте, или лыжи не едут...

    Я соверешенно запутался по поводу сертификации стандарта

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

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

    1. Роман Журавлёв

      Александр, здравствуйте!

      Коротко говоря, подтверждать знания и опыт можно или на основе ITIL, или на основе ISO 20000. У каждого варианта есть свои преимущества и недостатки.

      Попробуйте почитать (www.cleverics.ru/ru/subje...sm-certification) и послушать (www.cleverics.ru/ru/subje...eo/347-webinar-4) про сертификацию, вероятно, ясности прибавится. Информация немножко устарела, но в целом там все верно.

      Актуальное краткое описание двух доступных в России вариантов сертификации — здесь(www.cleverics.ru/ru/subje...sm-certification), здесь (www.cleverics.ru/ru/subje...il-certification) и здесь (www.cleverics.ru/ru/subje...00-certification). Там же описано, что нужно сделать и сколько стоит, если делать это с нами.

  11. Василий

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

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

    Спасибо.

  12. Aleksandr Meshkov

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

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

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

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

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

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

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

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

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

  13. Сергей Журавлёв

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

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

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

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

    В свойствах элемента я указываю —

    «условие отображения»: [contact.severity]

    (значение булевое)

    Элемент находится в доп. области (НЕ основная форма)

    В виндос клиенте — элемент прячется/показывается

    А web-клиент — никак не реагирует

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

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

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

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

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

  14. Александр

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

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

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

  15. Дмитрий

    Добрый день.

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

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

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

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

      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. Порядок и особенности внедрения (проектирования списка линий, вопросы автоматизации, разработка отчетности для контроля эффективности, связь с системой стимулирования, информирование персонала, ...)

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

      1. Дмитрий

        Да, спасибо за помощь, много направлений подсказали. Как понимаю в основном мне придется ориентироваться на зарубежные источники. Не подскажете таковые? Благо знания языка имеются, а то что у нас (кроме вашего сайта) толковых статей не имеется я понял только сейчас...

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

          Сразу скажу — много информации Вы не найдете — ни здесь, ни "там". Базовый источник информации — непосредственно книга ITIL Service Operation: http://www.tsoshop.co.uk/bookstore.asp?Action=Book&ProductId=9780113313136&CLICKID=003244. Вероятно можно рассчитывать на отдельные публикации на http://www.itsmportal.com/ или аналогичных площадках. У нас здесь тоже есть немножко. Навскидку помню:

          1. http://www.realitsm.ru/2013/02/pickup_time_as_kpi/

          2. http://www.realitsm.ru/2012/09/functional-escalation/

          3. http://www.realitsm.ru/2011/06/autoassignments/

          4. http://www.realitsm.ru/2010/11/vzaimodejstvie/

          5. http://www.realitsm.ru/2013/04/how-to-escalate/

          Но, как я и говорил выше:

          готовых материалов практически нет

  16. Евгений

    Добрый день!

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

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

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

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

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

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

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

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

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

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

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

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

     

    Спасибо!

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

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

      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 и с самим владельцем).

  19. Елена

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

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

    Ваше мнение?

  20. ITSM вопрос

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

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

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

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

    День добрый!

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

    Спасибо!

  22. Андрей

    Коллеги,

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

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

     

  23. Сергей Зайцев

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

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

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

  24. Наталья

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

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

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

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

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

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

  25. Александр

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

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

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

  26. Oleksandr Vinnytskyi

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

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

  27. Рафхат

    Добрый день!

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

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

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

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

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

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

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

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

    Спасибо!

    1. Олег Скрынник

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

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

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

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

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

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

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

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

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

  29. Игорь

    Добрый день.

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

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

    Спасибо.

  30. Дмитрий

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

    Подскажите, пожалуйста, поставлена задача определить влияние 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 по вине недоступности сервиса

     

     

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

     

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

  31. Александр

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

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

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

  32. Анатолий

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

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

    Например,

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

    Шаг 2

    ...

    Шаг N -1

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

  33. Сергей

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

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

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

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

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

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

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

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

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

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

    Для РГ2 TPI = 0

    А для РГ 1?

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

    Или же 1 ?

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

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

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

  34. Вячеслав

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

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

     

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

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

     

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

     

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

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

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

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

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

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

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

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

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

  36. Игорь

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

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

  37. Дмитрий

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

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

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

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

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

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

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

     

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

     

     

     

  38. Вадим Древин

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

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

    В книге "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 значения, но среднего там нет :).

  39. Эльдар

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

  40. Альберт

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

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

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

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

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

    Спасибо

  41. Ксения

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

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

    1. Алексей Юсов

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

      1. Алексей Юсов

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

        1. Ксения

          =D

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

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

          1. Ксения

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

  42. Олег Цыганов

    Всем привет. 

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

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

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

  43. Maryna

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

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

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

    Спасибо!

    Марина

  44. Балжан Курманова

    Добрый день,

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

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

  45. Rafhat Osmonov

    Добрый день!

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

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

    И конечно же в чем ценность вышеуказанных процессов?

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

    Спасибо!

    1. Денис Денисов

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

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

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

      1. Rafhat Osmonov

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

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

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

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

  46. Дмитрий

    Добрый день,

     Внутри команды 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? И какие вы видите сложности в этом?

     

    Спасибо 

  47. Денис

    Добрый день.

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

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

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

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

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

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

  48. Антон

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

     

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

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

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

     

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

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

     

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

     

     

  49. Станислав

    Добрый день!

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

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

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

    У нас в проекте используется классический RBAC (без расширений).

    Небольшой пример ролей и привилегий из нашего проекта "Роль{permission1, ...}":

    * Врач{чтение_своих_пациентов}

    * Гл.Врач{чтение_своих_пациентов, чтение_пациентов_в_своей_организации}

    * Статистик{чтение_отчет_#1_по_своим_пациентам}

    * Гл. статистик{чтение_отчет_#1_по_пациентам_в_своей_организации}

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

    * чтение_пациентов_в_подчиненных_организациях

    * чтение_отчет_#1_по_пациентам_в_подчиненных_организациях

    Динамические ограничения:

    * Федеральный округ — чтение пациентов/формирование отчета_#1 ограничено конкретным федеральным округом

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

    Понятно, что эти ограничения можно представить в виде привилегий:

    * чтение_пациентов_региональный уровень

    * чтение_пациентов_федеральный уровень

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

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

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

    А раз так, то почему бы ограничения: "мои_пациенты", "моя_организация", "подчиненные_организации", "региональный_уровень", "федеральный_уровень", "привязка ко времени" не вынести в отдельный

    механизм?

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

  50. Станислав

    Добрый день!

    Вопрос касается области управления доступом (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

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

  51. Ленар Рахматуллин, рук. отд. Сервис Деск, 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?

  52. Анна Закускина

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

     

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

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

    Хотелось бы научиться вот чему

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

    — оценивать сроки проектов (а соответственно бюджет). Соотносить бюджет задач с их полезностью.

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

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

  53. Александр Т

    Добрый день!

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

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

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

    Спасибо

    1. Nargiza Suleymanova

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

  54. Дмитрий

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

    Помогите разобраться с ситуацией просчета показателя 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. Но такой подход выглядит сложно реализуемым. Ваше мнение?

     

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

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

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

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

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

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

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

    — что-то еще...

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

  56. Никита

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

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

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

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

    Срок решения инцидента определяется его влиянием.

    Шкала влияния состоит из двух значение:

    1 — за один час инцидента с таким влиянием бизнес теряет 1$

    2 — за один час инцидента с таким влиянием бизнес теряет 2$

    Сроки решения инцидентов:

    1 час — для инцидентов с влиянием 1

    30 минут — для инцидентов с влиянием 2

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

    Изменение (зафиксированного) влияния инцидента может происходить по двум причинам:

    1) Ранее влияние было неверно определено (то есть ранее влияние самом деле было таким, каким мы его фиксируем после изменения)

    2) Влияние на самом деле изменилось (например, выросло вследствие дальнейшей деградации сервиса)

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

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

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

    Таким образом мы сохраним максимальное влияние на бизнес на необходимом уровне.

    Какие плюсы/минусы вы видите в данном подходе?

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

  57. Дмитрий

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

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

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

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

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

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

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

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

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

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

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

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

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

     

  58. Арсен Юрьевич

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

    ITIL® Foundation

    ITIL® Intermediate OSA Module

    ITIL® Intermediate SOA Module

  59. Александр

    Добрый день!

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

    www.exin.com/RU/en/media/...tnership-in-2018

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

    1. Игорь Гутник

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

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

      Очевидно, что основной риск [любой] монополизации – это повышение цен (и аналогичные возможные побочные явления монополизации).

      Во всём остальном ни партнёрам, ни уж тем более конечным заказчикам беспокоиться не о чем.

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

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

       

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

  60. Александр

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

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

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

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

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

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

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

  61. Дмитрий

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

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

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

  62. Роман

    Добрый день.

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

  63. Андрей

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

  64. Ольга

    Добрый день!

    В 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. Не могли бы вы пояснить, что это за сущности и в чем разница? Спасибо!

  65. Дмитрий

    Добрый день,

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

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

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

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

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

     

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

  66. Анна Лобова

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

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

    Спасибо!

     

  67. Арсен Юрьевич

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

  68. Pavel

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

  69. Анна Лобова

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

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

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

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

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

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

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

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

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

    Спасибо.

  70. Владимир

    Добрый день!

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

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

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

  71. Динара

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

     

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

  72. Андрей

    Добрый день.

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

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

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

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

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

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

  73. Ольга

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

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

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

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

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

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

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

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

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

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

    Спасибо!

  74. Анна Лобова

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

    Спасибо!

  75. Александр

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

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

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

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

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

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

    Спасибо!

  76. Екатерина

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Спасибо!

     

     

     

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
28