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

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

Дмитрий Исайченко

Директор по консалтингу Cleverics. ITIL Expert, IT Service Manager, Certified ITSM Consultant.

SLM-позитив

Сегодня получил очень яркое впечатление от обсуждения с представителями бизнес-подразделения одного крупного банка состава предоставляемых ИТ-услуг и структуры SLA. Скажу так: многочисленные выступления в духе «не понимают они ITSM» – весьма односторонняя точка зрения. Я понимаю, не все бизнес-подразделения одинаковы, но от сегодняшней встречи у меня остались следующие наблюдения: бизнес задумывается о том, в чём заключается ИТ-обеспечение его деятельности и что требовать от ИТ-подразделения; бизнес конструктивен в диалоге, понимает, что требовать всего и прямо сейчас в принципе можно, но не очень полезно; понимая ограничения, бизнес тем не менее смотрит в будущее и хочет видеть, как сегодняшние ограничения при заключении SLA…

Между разработкой и эксплуатацией

Работая с разными компаниями, в последние годы мы несколько раз сталкивались с задачей определения требований к взаимодействию в триаде «проектный офис, разработчики, эксплуатирующие подразделения». Практика в этой области весьма разнообразна. Столкнувшись с этой задачей в очередной раз, решил кратко суммировать накопленный опыт (спасибо нашим заказчикам!). Итак, вот основной набор регламентирующих документов в этой области: Документ, определяющий основные стадии создания новой АС (новой версии АС) или выполнения доработок. Обычно называется «Положение о разработке прикладного ПО» или аналогично. Основное содержание – по каждой стадии определяется состав работ, ответственных, входные и выходные документы. Важный момент – вовлечение эксплуатирующих подразделений в определение требований и…

OLA-la

В последние годы я довольно много сталкиваюсь с практическими вопросами организации SLM и построения каталога ИТ-услуг. Одним из актуальных вопросов в этой области является назначение и содержание такого документа как Operational Level Agreement (OLA). Есть бородатый анекдот про хозяйку, которую соседка обвинила в том, что когда та брала у неё горшок, она вернула его треснувшим. Ответ был таков: «Во-первых, это неправда – я вернула его целым. Во-вторых, когда я брала горшок, он уже был треснувшим. И в-третьих, я вообще его не брала». Так вот, про OLA я могу сказать буквально следующее: во-первых, такого документа не существует, а во-вторых применение OLA…

Радуемся новостям в OMNITRACKER 9.3

При подготовке очередного планового релиза CleverENGINE (предыдущий вышел в январе 2012) мы прорабатывали вопрос планирования трудозатрат. Очень пригодилась новая функциональная возможность OMNITRACKER 9.3 отображать на план-графиках сведения о загрузке ресурсов. Получается симпатично (см. картинку), даёт наглядное представление о плановой загрузке при распределении новых задач. Теперь будет можно не только вести учёт фактических трудозатрат, но и планировать ресурсы. Ну а что это будет за новый релиз и почему я считаю его серьёзным прорывом, узнаете чуть позже (я конечно имею ввиду в мае 2012, а не в 2013 году). Недолго уже осталось 😉

Управление изменениями и релизами: один или два процесса

Мы-таки провели этот вебинар (давно уже собирались). Вопрос поднимался неоднократно, системного ответа не было. Теперь, как мне кажется, есть: https://cleverics.ru/subject-field/webinars/46-core/webinars-and-video/380. Если есть вопросы – велкам, обсудим. Специально для этого и создал этот пост.

Разрушители легенд: документы SLM

Когда люди задумываются об организации процесса управления уровнем услуг, они сразу вспоминают несколько ключевых документов SLM. И среди них, как правило, возникают: каталог услуг (с делением на бизнес-услуги и технические услуги), SLA и OLA. Эта ассоциация между процессом и его документами весьма устойчива. И, по крайней мере, иногда (будем аккуратны в формулировках) срабатывает сама собой, без размышления на тему необходимости этих самых документов в данном конкретном случае. Начнём с технических услуг и OLA. По-серьёзному это конечно разговор не на 5 минут. Но если быть кратким, наличие каталога технических услуг и OLA почти всегда недооценивается по последствиям в виде влияния на…

Выделенные менеджеры процессов

В большинстве организаций, с которыми мне доводилось работать, менеджеры процессов ITSM совмещали свои процессные обязанности с должностными, то есть были предметниками. Даже менеджеры процесса управления инцидентами довольно часто «на самом деле» были начальниками группы первой линии поддержки. Компаний, где роль менеджера того или иного процесса исполнялась выделенным сотрудником, меньшинство. А жаль. Есть вполне логичные сочетания ролей, которые в крупной компании тянут на 100%-ную загрузку. Например, SLM+PRB, CHG+CFG, INC (даже без совмещения). Выделенный менеджер обладает не только бОльшими ресурсами, но и может более правильно позиционироваться в организации, поскольку он при этом не будет являться начальником одного из отделов, который не должен…

Правда про уровни зрелости процессов

Недавно, работая с COBIT, в очередной раз наткнулся на очень важный текст про уровни зрелости (maturity) процессов (правильнее конечно говорить об уровне организации, но сейчас не об этом). Поскольку провожу обследование, зацепило. Тезисно содержание таково (страницы 17-18): В отличие от CMMI, COBIT не претендует на возможность точного расчёта уровня зрелости, поскольку… один и тот же процесс может одновременно иметь признаки разных уровней зрелости, что не позволяет однозначно утверждать, на каком уровне зрелости он находится (очень напоминает принцип суперпозиции состояний квантовой системы), поэтому… уровни зрелости используются только в качестве наглядной иллюстрации к текущему состоянию процесса или к разнице между текущим и…

Нужен консультант

Уважаемые коллеги, мы ищем на работу консультанта. Описание вакансии размещено здесь: https://cleverics.ru/about/job. Там же – порядок действий для желающих попасть на эту работу. Если Вы решили попробовать, должен предупредить о двух вещах: придётся много работать и много учиться.

Процессная математика. Tension-метрики

Итак, задача. Есть две tension-метрики, из них необходимо сделать один общий KPI, который показывал бы, насколько удаётся исполнителю обеспечить баланс. Для примера возьмём предложенные метрики процесса управления инцидентами по своевременности (https://realitsm.ru/2011/12/measuring-incident-management) и результативности (https://realitsm.ru/2012/02/measuring-incident-management-2). О каком балансе речь? Можно иметь неплохие показатели своевременности, если сразу перекидывать входящие обращения на смежников (а там жизнь покажет, можно в фоне поразбираться, вдруг и правда вопрос к нам). Однако в этом случае обращения будут возвращаться и требовать повторной обработки. Можно, напротив, разбираться «от и до», не передавать обращения (не отмечать выполнение), пока не будет 100%-ной уверенности в том, что найдено лучшее решение и оно…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM