Business Agility, DevOps, ITIL, ITSM, COBIT, PRINCE2, TOGAF, Kanban...
12 лет в эфире. 2 800+ записей. 10 000+ подписчиков.
Многие, начиная контролировать свои конфигурационные единицы (КЕ), в итоге оказываются в растерянности и в состоянии «тумана в голове» от переизбытка данных. Пытаясь одним махом взять под контроль все имеющиеся данные, легко оказаться обескураженным или подавленным масштабами задачи.
Когда на курсе мы разбираем варианты определения границы ответственности в сервисных отношениях, в качестве одного из примеров берём услугу «печать». Ту самую, что в том или ином виде представлена в любой организации. Ведь в почти в любой организации ИТ отвечает за то, чтобы у сотрудников организации была возможность распечатать документы. Принтеры, МФУ и вся инфраструктура, включая принт-серверы, системы мониторинга и т.д. и т.п. Иногда кажется, несмотря на большое количество деталей, которыми мы в обсуждениях различных сценариев нагружаем этот пример (а может быть как раз из-за них 😊), некоторые слушатели воспринимают это как какой-то незначительный вопрос. Ну, то есть всё понятно...
В настоящее время реагирование на инциденты в большей степени направлено на упреждение и попытку полного предотвращения инцидентов. Что такое реагирование на инциденты? Инцидент — это событие (выход из строя сети, отказ системы, утечка данных и т.д.), которое может привести к потере или нарушению работы, услуг или функций организации. Реагирование на инцидент — это усилия организации по обнаружению, анализу и устранению опасностей, возникших в результате инцидента. В наиболее распространенных случаях, когда упоминается реагирование на инциденты, оно обычно относится к инцидентам безопасности. Иногда понятия «реагирование на инциденты» и «управление инцидентами» используются как взаимозаменяемые. Однако инцидент может быть любого характера, он не обязательно...
Один из советов, который я предложил, заключался в том, что им следует определить свою склонность к риску («риск-аппетит») таким образом, чтобы помочь людям понять, какие риски будут считаться приемлемыми, а когда им следует быть более осторожными.
В недавней статье «Сдвиг влево: создание ценности в Scrum» («Shift Left: Value Creation in Scrum») Стефан Волперс, обращает внимание на то, что формирование ценности в Scrum не такая уж простая штука. Как замечает автор, какими бы ни были эффективны в Scrum-команде разработчики (developers), если на вход в производственную систему поступает ерунда, то эффективность всей системы не будет максимальной («Garbage in, garbage out»). {здесь люди, привыкшие к конструкции уровней «стратегический – тактический — операционный», возможно, вздрогнули; но, на самом деле, в данном случае это несущественно} Основная идея автора в том, что большая часть описания фреймворка Scrum посвящена описанию устройства производственной системы: от...
Обсуждая тему построения эффективной поддержки в ИТ или оптимизацию работы уже существующей, мы всегда сталкиваемся с вопросами измерения. Что измерять? Как измерять? Зачем измерять? Современные технологии Service Desk и выгрузка разных отчетов позволяют легко собирать большие объемы данных о производительности, рациональности, удовлетворенности. Признанными показателями эффективности для Сервис деска будут: Но сегодня я хотел бы затронуть тему удовлетворенности не потребителя, а сотрудника Сервис деска или, как сейчас принято называть, агента. А измеряете ли вы этот параметр вообще? Волнуют ли вас вопросы удовлетворенности работой вашего персонала? Или эти вопросы могут всплывать только при появлении текучести кадров? Удовлетворенность Поговорка о том, что счастливые...
Разработка продукта — это почти всегда командный вид спорта. Но заставить «разработчиков» и «не разработчиков» (заинтересованных лиц, не являющихся инженерами) хорошо работать вместе не так уж и просто. Почему? Разбираемся.
Практически для всех компаний 2022 год стал годом глобальных перемен и неопределенности — и приоритеты ИТ меняются по мере того, как компании адаптируются к новым условиям — главная мысль в отчете Cisco 2023 Global networking trends report. При создании отчета было опрошено более 2500 ИТ-руководителей в 13 странах на предмет роли сетевых технологий в успешной облачной стратегии. Отчет показал, что на ИТ-команды возлагается как никогда большое давление, поскольку им необходимо соответствовать постоянно меняющимся требованиям, развивать сетевые технологии, таланты и операции, чтобы поддерживать цифровые преобразования и мультиоблачные проекты. Основные выводы Бизнес-тренд: Подразделения бизнеса высказывают свое мнение Растущее влияние направлений бизнеса на...
Лидеры отрасли говорят, что высокоэффективные сотрудники их команд обладают схожими качествами, которые полезно выявлять при подборе персонала
Service mindset — термин Шрёдингера. С одной стороны — мы не очень понимаем, что это такое: каждый авторитетный ITSM-гуру определяет его по-своему. С другой — изучая зарубежные статьи или принимая участие в онлайн-ITSM-баталиях — это словосочетание очень легко встретить.