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

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

Практика и опыт

Примеры реальных задач, истории успеха и решения из жизни

Вопрос из зала: как классифицировать инциденты по ИТ-услугам?

Посетитель нашего портала Дмитрий задаёт следующий вопрос: Коллеги, добрый день. Интересует как правильно связывать инциденты с затронутыми ими бизнес-сервисами. Пример 1: клиент не смог перевести средства на счет телефона через интернет-банк и обратился в поддержку -> зарегестрировали инцидент с привязкой к бизнес сервису "Платежи и переводы в ИБ". Тут всё понятно. Пример 2: Ответсвенный специалист обнаружил сбой в процессинговой системе (либо пришел алерт от системы мониторинга). Этот сбой влияет / может влиять не только на проведение платежей в ИБ, но на операции в банкоматах / ТСП / интернете и т.п.  – В данном случае, первая линия должна связять инцидент со всеми затронутыми / потенциально затронутыми бизнес-сервисами или каким-то…

Портрет менеджера ИТ-услуги

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

Сколько на самом деле занимает учёт рабочего времени

C октября 2013 года я веду учёт собственного рабочего времени. Первые 13 недель, аккурат до конца года, он был довольно простым: я учитывал каждую потраченную минуту и относил её к одной из категорий (известный светофор руководителя "красное, жёлтое и зелёное время"). Это делалось сразу, как только одно дело закончено, при переходе к следующей задаче (а не в конце дня по памяти). Выглядело это вот так: При известной автоматизации упражнение оказалось несложным, но получаемая аналитика довольно скудной, поэтому с 1 января 2014 года я добавил отнесение потраченного времени по категориям (всего 18 штук), а также решил вести не сразу сводную таблицу, а…

Проводим процессный бенчмаркинг: где посмотреть значения основных метрик?

Игорь, посетитель нашего портала, ищёт ответ на следующий вопрос, который возник у него после прочтения книги "ITSM. Руководство по измерению":   Добрый день, коллеги! в книге itsm — руководство по измерению есть ссылка на то, чтоб не забывали про бенчмаркинг по метрикам, которые публикуют аналитические агенсства. где можно посмотреть на эти метрики? оччень нужно и важно

Система определения приоритетов одной известной компании

В одной компании уже много лет действует такая система определения приоритетов неприятных событий (мы бы называли их инцидентами, наверное): Код Sev-5, самый низший, используется для относительно незначительных проблем, как правило технических. Такие проблемы можно и нужно решать в обычном рабочем порядке. То есть — не очень срочно, но сделать нужно. Код Sev-1, самый высший, присваивается срочным событиям, реакция на которые должна быть безотлагательной: запускаются все возможные системы оповещения ответственных сотрудников, приступить к устранению беды следует немедленно, о проблеме, её последствиях и героическом устранении будет доложено одному из топ-менеджеров компании, который не только выслушает, но и сделает орг.выводы и примет административные…

CMDB как инструмент учёта прав доступа

Ярослав спрашивает авторов и читателей портала: Просьба посоветовать хорошие практики по учету прав доступа к информационным системам (бизнес-сервисам). Цель: учесть возможные права доступа к каждой системе и выданные права доступа каждого пользователя к каждой системе. Использовать это в заявках на запрос, изменение, отключение прав, для отчетности и аудита прав. Сейчас это представляется мне так: для каждого права доступа к системе создается отдельный класс  CI в CMDB. К CI "Информационная система" привязываются все CI "Право доступа…", имеющие к ней отношение. Пользователи привязываются к CI "Право доступа…", в соответствии с выданными им в реальности правами. Есть ли какой-то другой подход к решению такой задачи? Заранее благодарю!

Новый сезон вебинаров CleverTALK

Вебинары CleverTALK стали настолько привычным и ожидаемым событием, что многие слушатели с нетерпением ждут начала очередного сезона. Между тем очередной сезон станет уже восьмым: вебинары проводятся с 2011 года. За это время проведено более 60 вебинаров, на них зарегистрировалось более 9 000 участников. Записи прошедших вебинаров набрали более 130 000 просмотров.  В восьмом сезоне вас ждет восемь интересных вебинаров от наших тренеров и консультантов. Перед каждым сезоном мы очень тщательно готовим список тем. В этом году при составлении списка мы постарались учесть вопросы, которые нам часто задают на проектах и учебных курсах. Вот что мы в итоге выбрали для вас: Строим Dashboard ИТ-руководителя Полезная CMDB: первые шаги Современные стандарты…

KPI, проценты и психология

Используя первую главу книги «ITSM. Руководство по измерению», можно сформировать оценку ИТ-подразделения или отдельных видов деятельности. В книжке эти оценки выражены в процентах и измеряются от 0 до 100. Однако опыт показывает, что проценты иногда вызывают неприятие руководителей. И причины этого не в математике, а скорее в психологии. Вот пример. Допустим, оценка качества некоторой услуги опирается на три показателя: В ответ на подобные таблицы мы несколько раз получали от ИТ-руководителей замечания вроде «Что значит 0%? Это значит, мы вообще могли выключить системы и не включать их?» или «Что значит 60%? У нас доступность на уровне 99%, а за 60% нас вообще…

Почему компании не любят своих клиентов?

​Есть такая полезная штука — Customer Lifetime Value. Современные технологичные компании любят её подсчитывать разными способами (единой стандартной формулы пока нет). Даже в самом упрощённом варианте, без учёта дисконтирования и усредняя всё, что можно, в расчёт принимают выручку с клиента, маржу и коэффициент оттока клиентов. Перемножая первое на второе, и деля на третье, зачастую получаются довольно внушительные суммы. Например, оценка для сети кофеен Starbucks даёт суммы от 5 500 до 25 000 американских долларов на одного клиента. Современные технологичные компании очень стараются повышать выручку, увеличивать маржу, и снижать отток клиентов. Подставляя изменённые значения в ту же формулу, всё большее число руководителей и сотрудников таких компаний осознаёт,…

Операционные стандарты – практическое развитие идеи OLA?

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

Отсутствие выделенных групп поддержки – каковы преимущества?

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM