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

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

Аналитика: точка зрения

Мнение авторов может не совпадать с их точкой зрения

О ценности и цене

Говорят, однажды Владимир Познер на традиционный вопрос Ларри Кинга "Чтобы Вы спросили у Бога, если бы у вас был только один вопрос?" сказал: "Как тебе не стыдно?". Один вопрос, понимаете? Нелегко, если не подготовился. Но это вступление, а теперь – к сути. На днях мне посчастливилось познакомиться с новым (Q4 2010) гартнеровским магическим квадратом (далее – MQ) по ITSM-продуктам (у кого нет – ищите в интернете и обрящете). Если кратко, теперь у нас остался один лидер – BMC Remedy ITSM Suite. Все остальные (включая HP, CA, IBM) … скажем так "потеряли в своих позициях". Я сначала очень удивился и даже…

Еще немного путаницы…

В своей заметке Скептик обращает внимание на интересные рассуждения авторов официальной сертификации ПО на совместимость с ITIL: поскольку критерии оценки опубликованы и известны производителям ПО, степень соответствия, ожидаемая оценщиками, должна быть большей, чем раньше (когда критерии известны не были, и производители обеспечивали соответствие "наугад"). "Большей" – это 100%.  Если допустить, что основными заинтересованными в сертификации участниками рынка являются все-таки покупатели ПО, то возникает вопрос: а как отличить сертификацию, подтвердившую полное соответствие (сейчас) от сертификации, подтвердившей какое-то соответствие (до публикации критериев)? В частности, большой красивый продукт от компании BMC, получивший сертификат первым, – он насколько соответствовал критериям оценки?

Самая важная и самая трудная часть ITSM-проекта

В своей очередной колонке на ITSMPortal.com Роман Журавлёв сделал попытку применить к специфике ITSM-проектов методику поддержки культурных (организационных, поведенческих…) изменений, разработанную компанией VitalSmarts.  Любой ITSM-проект предполагает изменение культуры, то есть того, как люди выполняют свою работу и того, как они к этой работе относятся. Такие изменения – самая важная часть ITSM и при этом наименее исследованная, а в проектах ей часто уделяется непростительно мало внимания. Как любое изменение, изменения в культуре и организации работ встречают сопротивление на самых разных уровнях. Без специальных шагов, направленных на преодоление этого сопротивления проект практически обречен. В то время как процессам управления ИТ-услугами посвящена целая…

Чего ждут CFO от ИТ-директоров

2009 год заставил многие компании по-новому взглянуть на управление финансами. В частности, изменилось отношение финансовых руководителей к тратам на ИТ: теперь в споре "цена-качество" все чаще выигрывает цена, и предпочтение отдается более экономичным решениям, пусть в ущерб функциональности.  Computerworld.com опубликовал большую статью о том, какими правилами следует руководствоваться ИТ-руководителю, отправляясь к финансовому директору за деньгами. Среди этих правил – следующие: Забудьте о желательном. Ограничьтесь необходимым. Используйте решения, которые у вас уже есть. Ясно представляйте себе, что нужно бизнесу прямо сейчас. Подготовьте внятное обоснование инвестиций. Учитывайте краткосрочные выгоды,  …но не забывайте и про долгосрочные преимущества. Подробности – на Computerworld

CSI и управление проблемами: кто сверху?

Michael Crooon в своей колонке на ITSMPortal, озаглавленной "Что общего у ITIL и Камасутры?" рассуждает о практике постоянного улучшения услуг (ИТ-услуг, разумеется).  Основная идея такова: для реализации на практике постоянного улучшения услуг можно и нужно использовать механизмы управления проблемами. Для этого нужно расширить перечень процессов, поставляющих процессу управления проблемами информацию для анализа и расследования. Обычно основным источником такой информации оказывается управление инцидентами; автор же предлагает варианты использования управления проблемами в интересах SLM, управления информационной безопасностью, управления жизненным циклом (приложений?)…    Полный текст колонки с таблицами и картинками – на ITSMPortal'е.   Ответ автора на вопрос из заголовка его колонки: ITIL and…

Ода V-модели

В своей колонке на ITSMPortal'e John Worthington описывает любимую игрушку авторов книги Service Transition, действительно полезную и толковую штуку – V-модель. V-модель наглядно демонстрирует основные этапы проектирования, конфигурирования и передачи в эксплуатацию новых или изменяемых услуг.  Автор сложил в честь такого полезного инструмента оду, вольный перевод которой мы публикуем.  Оригинал – на ITSMPortal.com   Я хочу, чтобы все здесь уразумели Красоту и полезность V-модели. Это не просто буква знакомая, Это волшебная пуля искомая.   Она нам покажет жизнь сервиса трудную – От первичной задумки, сквозь дискуссии нудные, Переделки и тесты – от ошибок очиститься – Прямо в эксплуатацию, где он будет…

Управление конфигурациями – не вещь, а практика

  ИТ-скептик опубликовал небольшую заметку об управлении конфигурациями и роли CMDB в этом процессе. Для удобства обсуждения мы публикуем ее полный перевод.  ITIL определеяет управление конфигурациями как предоставление информации, но затем на множестве страниц описывает его как сопровождение статичного хранилища данных, а не как активную деятельность по предоставлению информации заинтересованным в ней получателям. Давайте все же договоримся: управление конфигурациями – это процесс, а не вещь. («Процесс» – в  том вульгарном понимании этого слова, в котором его использует ITIL. Если вы не согласны с ним, замените «процесс» на «практику» или «деятельность».) Совершенствование управления конфигурациями – это совершенствование предоставления информации другим практикам…

Неортодоксальный взгляд на жизненный цикл услуг

Несколько еретических замечаний о структуре и сути жизненного цикла услуг сделал в очередной колонке на ITSMPortal.com Роман Журавлёв. Взяв за основу группировку процессов жизненного цикла ИТ-услуг из ITIL v3, он предложил для каждой фазы цикла формулировки целей, соответствующие реальному содержанию описанных в них процессов. Получилось совсем не так, как в ITIL.  Подробности на английском – на ITSMPortal.com Возможность разгромить еретика в пух – прямо здесь.

Каталог ИТ-услуг: как приручить дракона

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

Опять ИТ ломают бизнес

Недавно ИТ-скептик разместил в своем блоге заметку о том, как ИТ-проекты разрушают нормальную работу бизнеса. Вкратце ее основные тезисы таковы: Раньше большие проекты предполагали привлечение внешних ресурсов для формирования временных команд. Сейчас мы все больше отвлекаем для этих целей персонал операционных служб. Результат – снижение качества на обоих фронтах и нехватка ресурсов. Бизнес требует внедрения новейших технологий независимо от их полезности. Мы не осознаем всего объема выполняемых ИТ-проектов, не видим полной картины и, следовательно, не управляем ИТ-проектами. Бизнес также не учитывает сложности и критичности современной ИТ-архитектуры. ИТ не имеет возможности сказать бизнесу "НЕТ!". Неоправданным спросом на инновации никто не управляет….

Управление мощностями, как оно есть

На днях опять вспомнилась тема управления мощностями. Столько всего понакручено вокруг нее. Решил немного про это порассуждать. Например, выяснилось, что иногда под управлением мощностями понимают мониторинг ИТ-ресурсов ("всякие железяки"). В лучшем случае, с определением пороговых значений и правил реагирования на их нарушение. И тут появляются вопросы и типичные ошибки: 1. Откуда взяться требованиям к мониторингу? 2. Откуда взяться пороговым значениям?3. Как реагировать? Что значит для нас превышение того или иного порога? Бывает, что на эти вопросы отвечают так (конечно утрирую): "собираем все важное, пороги поставили разумные, если жахнет, то разберемся". При таком подходе, есть риски: 1. За грудой данных не увидеть…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM