Business Agility, DevOps, ITIL, ITSM, COBIT, PRINCE2, TOGAF, Kanban...
14 лет в эфире. 3 000 записей. 10 000+ постоянных подписчиков.
Смотрите новое видео с примерами путешествия заказчика. Данный видеоролик открывает серию, посвящённую практическому применению концепции путешествия заказчика (customer journey), рассматриваемой на учебном курсе ITIL® 4 Specialist: Drive Stakeholder Value http://cleverics.ru/itil4-dsv Рассказывает Артём Мукосеев, ITIL Expert, ITIL Managing Professional, аккредитованный тренер по ITIL 4
В редакцию портала поступил вопрос по процессу управления проблемами: Если в качестве решения проблемы возможны: изменение настроек компонетов системы доработка (те реализация дополнительных функуций, которые не были в ТЗ) 1 и 2 относятся к процессу управления изменениями? или это разные процессы, какие?
На прошедшей неделе компания Rollbar (поставщик платформы постоянного совершенствования кода) опубликовала результаты исследования, которое провела независимая исследовательская компания Propeller Insight в конце декабря 2020.Исследование проводилось методом опроса репрезентативной (для США) выборки 950 разработчиков. Поскольку инициатива проведения исследования исходит от компании, бизнес которой – автоматизация работ по повышению качества кода, предсказуемым лейтмотивом отчёта видится значимость проблемы – борьба с дефектами ведёт к существенным потерям бизнеса, а ручной формат этой борьбы крайне неэффективен. Однако, если отбросить классическое «Я не верю в микробов. Их придумали продавцы мыла», любопытными кажутся цифры, полученные в результате опроса. 38% респондентов сказали, что тратят до 25% своего времени…
Организации, ставящие перед собой задачу контроля качества предоставляемых ИТ-услуг, измеряют показатель доступности. Что такое доступность услуги и как она измеряется в реальной жизни? Давайте разбираться. Недоступность ИТ-услуги является высшей мерой нарушения ее эксплуатационных характеристик. Потребительские характеристики ИТ-услуги становятся такими, что ее потребитель теряет возможность получать от услуги ценность. Каждодневной заботой поставщика услуг является поддержание этой самой доставляемой потребительской ценности, а значит и обеспечение непрерывности ИТ-услуги. Такое определение нарушения доступности часто вызывает раздражение, т.к. оно предельно неконкретно и не отвечает на вопрос владельца конкретной услуги, что это означает в терминах его услуги, как измерять недоступность, и тому подобные вопросы. Корень зла…
Рассмотрим поток создания ценности. Для измерения его эффективности настоятельно рекомендуется применять метрику Flow Efficiency. Действительно, ещё со времён увлечения Lean нам известно, что далеко не всё время, которое заготовка проводит в нашей производственной системе, над ней кто-то работает. Существенную часть времени она находится в очередях, в ожидании, перемещаясь между участками работы и так далее. Потери, одним словом. Плохо. И Lean, и Канбан-метод, и даже ребята из DevOps советуют измерять эффективность потока путём деления времени, потраченного на собственно работу по созданию ценности, на общее время, которое задача провела в потоке. К примеру, вот что написано в словаре книжки “Essential Kanban Condensed”…
В данной статье рассматривается десять лучших (по мнению автора) метрик для измерения производительности команды поставки. Измерение и отслеживание прогресса является ключом к успеху при выполнении любой задачи. Как известно, Если вы не можете измерить что-то, вы не можете это улучшить Метрика Назначение / описание Время цикла Измерение времени выхода на рынок новой функции, помогающей создать ценность для потребителя. Показывает скорость работы команды. Длительность от начала работ до запуска в днях/неделях Число релизов Измерение способности команды поддерживать бизнес-потребности в отношении времени выхода на рынок.Число релизов за период Предсказуемость спринта Измерение и сопоставление прогнозируемого и фактического времени поставки. Эту метрику можно использовать для…
Недавно я прочитал в ITIL 4 про семь руководящих принципов. Что ж, это действительно хорошие идеи, но чем больше я смотрю на них – и рассказываю про них на курсах по основам ITIL, – тем менее новаторскими они выглядят. Я только что понял, почему они кажутся такими знакомыми: почти про все из них я узнал 60 лет назад от своей бабушки, и я подозреваю, что она впервые узнала про них за 60 лет до этого от своей бабушки. Они действительно правильны и хорошо зарекомендовали себя, но я подумал, что будет полезно поделиться формулировками этих принципов от моей бабушки со всеми,…
Команды являются средоточием производства в организациях. Они создают программный продукт и обеспечивают его поставку. Как и любое средство производства, команда требует внимания и своевременного ухода. Компаниям необходимо следить за тем, чтобы когнитивная нагрузка на команду не была чрезмерной (о том, что такое “когнитивная нагрузка“, мы рассказывали в одной из наших предыдущих заметок), поскольку работа в условиях слишком высокой когнитивной нагрузки не позволит эффективно и надёжно создавать и улучшать разрабатываемое программное обеспечение. В своей заметке на IT Revolutions Мэтью Скелтон (Matthew Skelton) и Мануэль Пайс (Manuel Pais) продолжают рассматривать тему и рассказывают об обнаружении и ограничении когнитивной нагрузки для того, чтобы…
В редакцию портала поступил вопрос: Коллеги, доброго дня, поделитесь пожалуйста опытом. Есть ли у вас УСПЕШНЫЕ кейсы одновременного внедрения нескольких базовых процессов (инциденты\обращения\изменения\конфиг\проблем)? Какие дополнительные «грабли» были при таком внедрении и как удалось избежать эффекта паралича работы ИТ-службы (когда специалисты вместо обычных 10 заявок в периоде — начинают обрабатывать 4-5 а остальное время «тупят» в новом ServiceDesk-е с новыми окошками и привыкают указывать связи, типы, статусы и т.д. по инструкциям)? Заранее благодарю, Сергей.
Сегодня среди компаний, чей бизнес плотно завязан на ИТ, наверное, только ленивый не слышал про трансформацию, «agile-изацию» и прочие процессы повышения прозрачности и эффективности разработки. Многие попробовали различные методологии на себе – и что-то из этого получили, с тем или иным выхлопом. Давайте оставим за рамками обсуждения позитивный сценарий и поговорим о ситуации, когда вроде и ребят умненьких наняли, и продакта-проджекта им привели, и методологии все «по канону», а всё равно ИТ-отдел выдаёт не то, не с тем качеством, не в те сроки, и вообще всячески доводит бизнес до предынфарктного состояния. Появляется ощущение, что проблема глубже, чем казалось изначально, но…
Есть довольно ощутимые вещи, которые вы можете сделать, чтобы прокачать свои знания в ITSM: посетить учебные курсы, мастер-классы, деловые игры, семинары и тренинги. Что выбрать в этом многообразии и как учесть тенденции быстро меняющегося мира? Да, мир не стоит на месте и вслед за официальным объявлением AXELOS об отмене сертификации ITILv3, о котором мы уже писали, набирает обороты новая линейка курсов и сертификации ITIL4. Но что делать тем, которым нужны знания в области ITSM, при этом вопросы сдачи англоязычных экзаменов не так актуальны? А если еще учесть то, что материалов в публикациях «ITIL® 4 Practice Guide» намного больше, чем требуется…