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

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

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

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

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

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 на бизнес-услугу. Давайте взглянем на средний уровень, где расположены технические услуги и разберёмся с ними поподробнее. Предположим, что наша бизнес-услуга – это "ИТ-обеспечение спецдепозитарной деятельности". Тогда техническими услугами, обеспечивающими бизнес-услугу, будут сущности,…

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

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

Вопрос из зала: критерии формирования групп поддержки

Наш постоянный читатель и участник дискуссий на портале, Вячеслав просит совета аудитории про необходимые и достаточные критерии, которые можно было бы использовать при организации отдельных групп поддержки: Доброго времени суток. Вопрос к личному опыту по Support groups. Какие ключевые критерии вы бы посоветовали выбрать необходимыми и достаточными, для выделения отдельных Support Groups. Интересует как с точки зрения здравосмыслия Support model, так и с точки зрения реализации в ITSM приложении. Вопрос вызван тем, что при рассмотрении организации достаточно большого размера и ширины профиля, логичное желание выделить группы по матрице Операционный уровень/Сервис влечёт за собой желание пользователей системы плодить группы сотнями… Поэтому…

Как ускорить решение инцидентов на 40%?

Мы все время от времени сетуем на то, что, при всей своей разумности и логичности, ITSM страдает нехваткой числовых подтверждений пользы. Поэтому достижения, которые выражены в цифрах, всегда вызывают интерес. На днях один из наших заказчиков поделился с нами своим достижением: за полгода ему удалось сократить среднее время решения инцидентов на 40%. Достойный результат, не правда ли? Основа решения – организация такого способа обращения за техподдержкой, при котором существенно сокращается время на сбор информации по инциденту и на его маршрутизацию до нужной группы. Технически это было реализовано посредством некоторой программы, которая должна была постепенно вытеснить такие способы обращения в Service…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM