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

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

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

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

Какие данные о конфигурациях необходимы именно Вам?

Перевод статьи Стюарта Ренса (Stuart Rance). Оригинал: What configuration data do you need? Управление конфигурациями – это процесс сбора и управления информацией об услугах и поддерживающих их компонентах. Благодаря этому процессу обеспечивается доступность информации в том месте и в то время, когда она требуется. Таким образом, он является залогом бесперебойного функционирования различных ИТ-процессов управления услугами. При этом какие именно данные необходимо обрабатывать в рамках конкретного процесса, каждая компания решает самостоятельно. Разные подходы к управлению конфигурациями У меня создалось впечатление, что каждая ИТ-организация, в которой я работал, применяет собственный подход к управлению конфигурациями. Как я уже упоминал, объем информации, который собирается…

Эксперименты с Kanban, визуализацией и потоком создания ценности

У тренеров Cleverics есть замечательная возможность ставить эксперименты на людях изучать интересные штуки, наблюдая за слушателями. Разумеется, полезность наблюдений чуть более, чем полностью определяется именно слушателями. Неделю назад мне повезло: на открытую деловую игру "Проект Феникс" собралась исключительная команда. Интеллектуалы с богатым опытом, открытые всему новому – о такой группе тренер может только мечтать. Помимо мечтаний удалось проследить эволюцию визуализации. Сейчас поясню. Игра – про DevOps. А эксперты этого модного направления вовсю советуют обязательно проработать как минимум следующие ключевые вещи: поток создания ценности (Value Stream) определение завершения (Definition of Done) ограничение числа задач в работе (WIP Limit) ясную картину загрузки ресурсов…

Нужно просто все посчитать

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

Штрафная практика

Какие ассоциации возникают у большинства из нас при словах и словосочетаниях "SLA" / "Соглашение", "уровень обслуживания"? Практически у всех, с кем я общаюсь в профессиональной области, данный ряд обычно вызывает следующий: "измерение и оценка", "штрафы", "наказание поставщика услуг", "штрафные санкции". Вроде бы – здорово, что в головах ИТ-менеджеров глубоко засела такая однозначная и прямая связь между уровнем предоставления услуги и воздействием на поставщика услуг. "Украл, выпил – в тюрьму". Не оказал услуги на должном уровне – получай штраф! Но жизнь – штука многогранная, не терпящая только чёрного и белого. А потому и с Соглашениями об уровне предоставления услуг тоже не…

Люди, которые играют в игры

Нет, это не знаменитый Эрик Берн с его не менее знаменитой одноименной книгой. И ДА – это про людей и игры. Это про, что в мире ITSM (и не только) люди тоже играют в игры.  Игра – это как кусочек жизни, насыщенной событиями, которую участники проживают за один день. Игра – это то, что дает нам возможность быстрого осознания что и как устроено и происходит, и, не менее важно – как это можно сделать лучше. И в игре, и позже  – в жизни.  А чтобы все эти инсайты случились, нужно понимать что мы хотим от неё получить.От четко сформулированных ожиданий может зависеть…

Игра “Проект Феникс”: опыт участия в тренинге для тренеров

На прошлой неделе летал в Нидерландию, к любимым партнёрам в GamingWorks. Проходил тренинг для тренеров по новой игре "Проект Феникс". Не претендуя на путевые заметки, готов поделиться наблюдениями. Поездка оказалась в высшей степени полезной и воодушевляющей. Про тренинг Первый раз Пол и Ян нас учили году в 2005 или 2006 – тогда это было про игру "Apollo 13". Помню, как помимо стандартной программы мы их мучали бесконечным количеством вопросов: голландцы терпеливо отвечали, разъясняли, показывали. С тех пор и они провели не один десяток сессий ТТТ, и мы освоили не одну деловую игру. Тем не менее, именно обучением Ян владеет виртуозно….

Как построить управление доступом “изнутри”?

На прошедшем в прошлый четверг вебинаре про управление запросами и управление доступом один из слушателей задал мне вопрос – а как организовать управление доступом в компании. С чего начать? В каком направлении двигаться? Попробую рассказать, как бы я поступал, находясь "внутри" компании. Итак, я штатный сотрудник организации. Руководство поставило передо мной задачу организации процесса управления доступом. Что делать, к чему приступать в первую очередь? Я бы для начала уточнил, а что сейчас, при текущей организации процесса (а он явно существует, поскольку в организации есть информационные ресурсы, права доступа к ним выдаются и отзываются), не устраивает в процессе. Собрал бы замечания…

Достучаться до небес

Очень часто на курсах слышишь фразы «заказчик не заинтересован в нас», «он не видит в нас тех, кто может обеспечить его нужды», «как донести заказчику свою значимость и состоятельность», «заказчику в SLA интересна только одна строчка».   Бывает, что ИТ-департамент выступает с инициативой улучшить что-то в своей деятельности: оптимизировать шаги получения конечных результатов, сократить расходы, увеличить производительность, но терпит неудачи. Казалось бы, основательно подготовились – освоили какие-то подходы, методики, получили много знаний. Но не взлетает. Или быстро падает. В чем же дело? В зависимости от того, у кого созрела идея улучшений, то есть на каком уровне вертикальной организационной иерархии, нужно прояснить много…

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

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

Конфликт интересов

Очень многие из нас оказываются в ситуации, когда исполнение работ различного рода несет за собой конфликт интересов, вызванный природой этих работ.  Такие ситуации легко иллюстрируются разнообразнейшими жизненными примерами: Ответственность менеджера инцидентов и менеджера проблем, при возникновении сбоев; Исполнитель работ и Проверяющий; Инициатор проблемы (в ITSM смысле) и эксперт, ответственный за её координацию, обработку и устранение; Постановщик задачи и разработчик, разработчик и тестировщик; Менеджер по доступности и менеджер непрерывности. Тема является весьма чувствительной, особенно для тех, кто в силу необходимости, исполняет обе конфликтные роли. Хотел бы поделиться с вами теми подходами, которыми я руководствуюсь в своих проектных активностях при возникновении подобных ситуаций. Эти же…

Провокация: есть мнение, что управлять инцидентами скоро будет не нужно!

Если следовать заметке The End of Incident Management (as we know it!) Дага Теддера (Doug Tedder), в обозримом будущем управлять инцидентами будут роботы, впрочем, как полагает редколлегия, и писать заметки на портале RealITSM. Как вы думаете, как скоро такое может произойти, и что же будут делать люди? Итак, можете ли вы представить себе ITSM без процесса управления инцидентами? По мнению автора заметки, при всей своей важности, управление инцидентами – один из наименее эффективных процессов в ITSM. Успех или неудача здесь зачастую зависят от человеческого фактора. От того, как клиент воспринимает конкретную проблему. От его настроения. От того, как прошло общение…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM