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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

Вопрос из зала

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

Вопрос из зала про конфигурационные единицы

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

Проблемы и известные ошибки

Интересную задачку нам предложили некоторое время назад в разделе "Задать вопрос":  Расскажите пожалуйста преимущества (пользу) и недостатки (затраты) вариантов: 1. Известная ошибка это статус проблемы и тогда в системе автоматизации один объект. 2. Известная ошибка и проблема это 2 отдельных объекта. Любой, кто участвовал в построении процесса управления проблемами, наверняка, размышлял о разных вариантах реализации такого объекта, как известная ошибка. Поделитесь своим мнением, коллеги!

Определение “производительности”

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

CMDB, CMS, SKMS… еще что-нибудь?

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

CMDB: как совместить детальность и наглядность?

Василий занят построением CMDB. И вот какой у него возник вопрос: У нас в компании со временем устоялась трехуровневая модель предоставления ИТ-сервисов бизнесу. 1. Уровень бизнес-сервисов (бизнес-направления или бизнес-процессы). 2. Уровень ИТ-сервисов прикладного уровня (ИТ-сервисы, связанные с прикладным ПО и автоматизированными банковскими системами). 3. Уровень ИТ-сервисов системного уровня (ИТ-сервисы, связанные с системным ПО (например, СУБД, прокси) и сетью). Получается, что, с одной стороны, у нас есть связь сервисов между собой, т.е. бизнес-сервисы зависят от ИТ-сервисов прикладного уровня, а ИТ-сервисы прикладного уровня зависят от ИТ-сервисов системного уровня. Есть заключенные SLA с бизнесом и OLA внутри ДИТ. С другой стороны, сервисы зависят…

Как применить статусы, раз уж они есть?

Мария спрашивает: Как можно перевести статусы инцидентов "Pending Other (ожидание другого исполнителя?) ", "Referred (передан на рассмотрение)", " Resolved (решен)", т.е. к каким ситуациям их применять? Мы используем систему HPSM и решили расшифровать статусы для исполнителей. Быстро найти в интернете адекватную информацию не удалось. Буду благодарна за помощь! Уважаемые специалисты по адаптации жизни к HPSM и по статусам инцидентов – предлагайте варианты, пожалуйста!

Вопрос из зала: каталог поддерживающих услуг

Роман запрашивает передовой опыт: Уважаемые коллеги! Подскажите, пожалуйста, описан ли где-либо обобщенный опыт по составлению каталога поддерживающих услуг, на которые заключаются OLA? А именно, есть ли где-нибудь описанный каталог таких поддерживающих/операционных услуг? Мы считаем, что в большинстве ИТ-подразделений перечень операционных услуг должен совпадать, как минимум, на 80%. Готовы ознакомиться с любыми вашими мнениями по этому вопросу. Итак, есть ли примеры каталогов поддерживающих услуг?

Вопрос из зала: процедура актуализации типовых изменений

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

Вопрос из зала: такая разная эскалация

Александр спрашивает у нас: Здравствуйте уважаемые Эксперты! Хотелось бы задать такой вопрос. В чём принципиальное отличие функциональной эскалации от иерархической? Очень важно показать иерархическую эскалацию на конкретных примерах. Зарание спасибо за ответ. Подозреваем, что простые ответы Александра не устроят: Иерархическая Эскалация – Информирование или вовлечение руководителей более высокого уровня в ходе эскалации. Функциональная Эскалация – Передача инцидента,проблемы или изменения в техническую группу с более высоким уровнем компетенции в ходе эскалации. Что скажете, коллеги?  

Вопрос из зала: ITIL/ITSM и eTOM

Василий спрашивает: Как CОBIT, ITIL, ITSM позиционируют себя по отношению к TMForum? Если рассматривать службы ИТ как маленькую, а иногда и небольшую телекоммуникационную компанию, поставляющую услуги бизнесу своей, иногда очень большой территориально распределенной компании (Газпром, Русал, Сбербанк, Почта России)?

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

Александр Мешков интересуется экспертными мнениями по поводу своей новой идеи. В данный момент наша компания разрабатывает решение, позволяющее диагностировать инциденты «на лету», и нам хотелось бы услышать мнения уважаемых коллег о перспективах этой концепции – диагностики инцидентов «на лету». Суть концепции заключается в том, что сервисный запрос на пути от пользователя к Службе поддержки обрастает сначала диагностической информацией (первый и второй этапы), а затем и проектом диагноза (третий этап). Таким образом, когда Служба поддержки получает Снимок Инцидента, ей остаётся только удостовериться в правильности диагноза и применить адекватное ему решение. Более подробно алгоритм диагностики инцидентов «на лету» выглядит так. Первый этап….

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;