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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Консалтинг
по управлению ИТ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопрос из зала: «многослойная» поддержка

И вновь нам задают интересный вопрос из практики. Наталья спрашивает: Здравствуйте, коллеги! Есть ли какие-то рекомендации или стандарты в отрасли (или хотя бы best practices и ваши наблюдения), которые бы показывали рациональность введения дополнительного уровня поддержки? Сколько процентов кейсов должен закрывать каждый уровень поддержки, чтобы оправдать свое существование? Буду очень благодарна за ваш ответ. Коллеги, ждём ваших ответов в комментариях!

Вопрос из зала: доступность и её команда

Алексей Тюрин спрашивает на нашей страничке в Фейсбуке: Добрый день! Помогите пожалуйста разобраться в чем разница между reliability и dependability (нет в глоссарии). И то и другое согласно ГОСТУ — надежность — т.е. свойство объекта сохранять во времени в установленных пределах значения всех параметров... Тем не менее в другом контексте говорится, что depentability — это reliability и availability. В этом случае, если reliability — надежность, то что такое dependability? Безотказность? Т.е. безотказность это надежность и доступность (способность объекта выполнять согласованную функцию, когда это требуется). Правильным ли будет такой вывод? Спасибо! Давайте распутаем эту терминологическую красоту в комментариях.

Вопрос из зала: штрафы за неработающее ПО

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

Вопрос из зала: выбор системы автоматизации

Альберт задаёт вопрос: Компания, занимается продажами. Разветвленная сеть филиалов (40 шт). На данный момент установлен service desk OTRS, пользуется для регистрации заявок через единое окно (что очень тяжело дается) и для автоматического расчета уровня SLA. Количество ИТ сотрудников работающих с этой системой около 25 человек (10 в офисе, 15 по филиалам). В эту же систему подключили техническую службу (+ 20 человек). Система не гибкая (бесплатная). В ближайший год планируется развитие компании, и понимаю, что текущая система будет не удовлетворять потребностям (количество пользователей 100, заявок 1000—2000 ежедневно). Необходимо чтобы с ServiceDeskи SLA работали не только ИТ, а все сервисные службы компании,...

Вопрос из зала: упрощение эскалации

Наш коллега Евгений запросил совета у профессионалов. Вам, уважаемые читатели realitsm.ru, мы и адресуем следующий кейс: Добрый день! Хотелось бы спросить совета у профи. Наша компания занимается IT аутсорсингом. Из персонала мы имеем следующее: команда технической поддержки (первая линия – операторы, вторая линия – инженеры руки-ноги, третья линия – умные инженеры), команда сетевиков, которая занимается монтажом кабелистики, шкафов, ИБП, электрики и т.д., команда связи, которая занимается организацией работы IP телефонии на базе CISCO и команда виндовых серверов и сервисов, которая занимается серверами, почтой, фаерволами и прочими серверными компонентами. Суть проблема вот в чем: например, поступило обращение от пользователя: не звонит IP...

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM