Мастер-класс по Real ITSM

913 views
836 views

Published on

Первый в мире мастер-класс по Real ITSM был проведён в России первого апреля 2010 года компанией Cleverics.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
913
On SlideShare
0
From Embeds
0
Number of Embeds
66
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • На самом деле, Real ITSM – сатира. В свою очередь, ITIL – утопия. Давайте в самом деле побудем реалистами.
  • Мастер-класс по Real ITSM

    1. 1. Real ITSM Первоапрельский обзор реальности
    2. 2. Здравствуйте! <ul><li>Роб Ингланд (IT Skeptic) – создатель Real ITSM </li></ul><ul><li>Роман Журавлёв – переводчик “Introduction to Real ITSM”, директор по обучению компании Cleverics, ведущий преподаватель Учебного центра информационного менеджмента ВШБ ГУУ </li></ul>
    3. 3. Теория управления ИТ отлично подходит тем, у кого в избытке времени и денег <ul><li>Rob: «Недорогой, невредный, быстрый и простой, Real ITSM – это лучший подход для большинства современных ИТ-департаментов. Станьте реалистами.» </li></ul><ul><li>Роман: « Real ITSM – о том, как устроено управление ИТ-услугами на самом деле. А устроено оно, к сожалению, не очень хорошо. Поэтому не надо ждать от Real ITSM ничего хорошего.» </li></ul>
    4. 4. Назад, к реальности <ul><li>Real ITSM представляет реальные практики: управление ИТ сервисами, как оно происходит в реальном мире … </li></ul><ul><ul><li>… в России </li></ul></ul>
    5. 5. Модель Real ITSM <ul><li>« концепция «четырех П» (Персонал, Процессы, Продукты, Партнеры) больше не работает. Real ITSM использует другую модель: Народ – Активности – Хозяйство – Паразиты, сокращенно «НАХП» </li></ul>
    6. 6. Service Deathcycle Руководство, консультанты и сотрудники, занятые измерением и оценкой сервиса, должны чувствовать себя счастливыми. Постоянная оценка сервиса ( Continual Service Assessment ) Связавшись с сервисом, следует сконцентрироваться на том, чтобы он прожил как можно дольше, чтобы обеспечить максимальную прибыль. Пестование сервиса ( Service Nursing ) Сервисы приходят неожиданно и без предупреждения. Наша задача – взять их под контроль. Приручение сервиса ( Service Taming ) Создание сервисов – форма уступки в ответ на спрос со стороны бизнеса. Спрос на сервис ( Service Demand ) Планирование и стратегии запрещены. Любые действия Real ITSM – реакция на давление бизнеса. Реакция на сервис ( Service Reaction )
    7. 7. Service Deathcycle Руководство, консультанты и сотрудники, занятые измерением и оценкой сервиса, должны чувствовать себя счастливыми. Постоянная оценка сервиса ( Continual Service Assessment ) Связавшись с сервисом, следует сконцентрироваться на том, чтобы он прожил как можно дольше, чтобы обеспечить максимальную прибыль. Пестование сервиса ( Service Nursing ) Сервисы приходят неожиданно и без предупреждения. Наша задача – взять их под контроль. Приручение сервиса ( Service Taming ) Создание сервисов – форма уступки в ответ на спрос со стороны бизнеса. Спрос на сервис ( Service Demand ) Планирование и стратегии запрещены. Любые действия Real ITSM – реакция на давление бизнеса. Реакция на сервис ( Service Reaction )
    8. 8. Зрелость ИТ <ul><li>Оптимальный уровень зрелости – первый, хотя нулевой тоже подходит. </li></ul><ul><li>П рекращени е какой-либо активности (снижение до уровня 0) – это обычно здравое решение. </li></ul><ul><li>П опытки переместить активности на любой другой уровень зрелости рассматриваются как непродуктивные и требуют корректирующих мер. </li></ul>
    9. 9. Service Reaction <ul><li>В отличие от ITIL v 3, где всем желающим предлагается стратегический подход, Real ITSM полностью, совершенно, абсолютно реактивен. Как и стратегия сервисов ( Service Strategy ) в ITIL v 3, Реакция на сервис представляет собой эзотерическое знание, и не стоит с неё начинать . </li></ul>
    10. 10. Right Cycle <ul><li>Запретите постоянное улучшение. </li></ul><ul><li>Если система признана минимально пригодной к использованию, оставьте её в покое. </li></ul><ul><ul><li>Ей не так уж долго жить, так зачем вкладываться в улучшение того, что обречено в ближайшей перспективе? </li></ul></ul><ul><li>Любое реальное изменение должно быть основано на цикле братьев Райт: Предположение – Действие – Авария – Ремонт. </li></ul>Цикл назван в честь братьев Райт, сломавших немало самолетов до того, как им удалось поднять в воздух один из них.
    11. 11. Service Porthole
    12. 12. Service Cataract <ul><li>Один их наиболее важных документов в деле построения отношений между ИТ и бизнесом – Каскад сервисов. </li></ul><ul><li>Это перечень предоставляемых сервисов с указанием их взаимозависимостей. </li></ul><ul><li>Чем больше зависимостей у сервиса, тем больше условий придется выполнить заказчику для доступа к сервису </li></ul>
    13. 13. Каскад сервисов – основные виды <ul><li>Каскад-буклет, или Каскад Чу-Ши, где заказчикам обещаются разнообразные сервисы и их уровни. </li></ul><ul><ul><li>Цветной, много шрифтов, красочная обложка. </li></ul></ul><ul><li>Технический каскад, где мы для собственных нужд документируем реальные сервисы. </li></ul><ul><ul><li>Черно-белый, один шрифт, без обложки. </li></ul></ul><ul><li>Естественно, описания сервисов в этих документах не имеют ничего общего </li></ul>
    14. 14. Service Demand <ul><li>Несмотря на все наши усилия, заказчики настаивают на предоставлении им сервисов. Давление, оказываемое на CIO со стороны других высоких руководителей, и необходимость продолжать получать финансирование заставляют всё же обеспечить предоставление хоть каких-нибудь услуг. </li></ul>
    15. 15. Service Level Argument, SLA <ul><li>Д окумент, определяющий целевые характеристики сервисов, к достижению которых будет стремиться ИТ-департамент. </li></ul><ul><ul><li>И тем самым – значения, которые должен принимать бизнес. </li></ul></ul><ul><ul><ul><li>Здорово, если удается согласовать эти значения с бизнесом. </li></ul></ul></ul><ul><ul><ul><ul><li>Если нет – SLA носит односторонний характер. </li></ul></ul></ul></ul>Как правило, возможности ИТ по части измерения качества сервисов ограничены, а у заказчиков их вовсе нет. Поэтому результаты измерений обычно основаны на экспертной оценке. Погрешность при проведении такой оценки стоит делать в лучшую сторону, что поможет поддерживать дух сотрудников ИТ и не расстраивать пользователей.
    16. 16. Service Taming <ul><li>В том маловероятном случае, когда сервисы таки добираются до внедрения в продуктивную среду, задача ИТ-департамента – обеспечить их внедрение с минимальным влиянием на существующую инфраструктуру ИТ </li></ul>
    17. 17. Поймать, заклеймить, отпустить! <ul><li>Поскольку сервис был спроектирован без каких-либо средств мониторинга и метрик, служба эксплуатации отпускает его в продуктивную среду, в дикий опасный мир, где он будет жить и развиваться в основном без её участия и внимания </li></ul>
    18. 18. Изменения <ul><li>НЕ ДЕЛАЙТЕ ЭТОГО </li></ul>
    19. 19. Stuff <ul><li>Менеджеры Real ITSM управляют Хозяйством, известным также как «Активы» или «Конфигурации» </li></ul><ul><ul><li>Начальство или аудиторы периодически запрашивают список Хозяйства. Поскольку их требования абсолютно случайны и непредсказуемы, лучший способ работы – реагировать по мере поступления запросов, выделяя персонал для проведения переписи </li></ul></ul>
    20. 20. CMDB по имени Сью <ul><li>Византийская сложность современной ИТ-инфраструктуры означает, что единственные устройства, способные проконтролировать влияние изменения или сбоя какого-то компонента, это люди </li></ul><ul><li>Пусть вы внедрите самый супер-пупер продвинутый искусственный интеллект для анализа концептуальных структур данных, рано или поздно эта штука сморозит какую-нибудь страшную глупость. </li></ul><ul><ul><li>И все опять будут бегать к живому эксперту, чтобы перепроверить её заявления </li></ul></ul>
    21. 21. CMDB <ul><li>Мы в ней не нуждаемся, но должны её иметь. У всех ведь есть. И в книгах так написано </li></ul><ul><li>Разумеется, никто не может продать вам её. CMDB – это абстрактное понятие, вроде святости или честности </li></ul>
    22. 22. Service Nursing <ul><li>Стараниями проектировщиков, разработчиков и специалистов по развёртыванию, когда сервис оказывается в продуктивной среде, он почти наверняка нестабилен, неуправляем и бесполезен </li></ul><ul><li>М ы должны сделать всё возможное, чтобы он прожил как можно дольше при минимуме инвестиций </li></ul>
    23. 23. Управление проблемами <ul><li>Проблемы слишком важны, чтобы внедрять управление проблемами </li></ul><ul><ul><li>Как только у вас появится процесс – с владельцем, процедурами, записями, совещаниями, – все тут же смогут снова расслабиться и перестанут обращать на проблемы внимание </li></ul></ul><ul><li>Просто решайте их </li></ul>Решение проблем
    24. 24. Телефон <ul><li>Основное средство мониторинга </li></ul><ul><li>Помогает Service Desk с высокой точностью определять влияние и требуемое время восстановления </li></ul><ul><li>Делает ненужными все средства управления сервисами, мониторинга событий, оповещения, каталоги услуг и прочие излишества, используемые другими подходами в области ITSM </li></ul><ul><li>Дёшев во внедрении, использует высоконадёжные системы, имеет высокую доступность, не требует администрирования, а его сопровождение и обслуживание отданы на аутсорсинг </li></ul><ul><li>Н астоящий шедевр в мире ИТ-оборудования. </li></ul>
    25. 25. Service Desk <ul><li>Люди </li></ul><ul><ul><li>Постарайтесь найти таких, которые в самом деле любят других людей </li></ul></ul><ul><li>ПО </li></ul><ul><ul><li>Service Desk – единственное место, где софт имеет значение </li></ul></ul>
    26. 26. Приоритеты инцидентов … медового месяца Билл Гейтс ∞ Все, в том числе уволенные 7 … отпуска CEO 1000 Все 6 … домашних дел CIO 100 16 5 … проектов Менеджер по эксплуатации 24 8 4 … обучения Service Delivery Manager 8 4 3 … совещаний с сотрудниками Руководитель Service Desk 8 2 2 … блуждания по Интернету Админ 4 1 1 … чтения газет Пользователь .0025 1 0 Мы отвлечем их от… К валификаци я ответственного Часов в день Число сотрудников для решения Приоритет
    27. 27. Категоризация <ul><li>Технари любят полноту и точность, не говоря уж о нежном пристрастии к сложным, умным и изящным решениям, независимо от наличия задачи </li></ul><ul><li>ИТС: стремление делать вещи правильно , независимо от того, будет ли это полезно, рационально, выгодно и разумно – то есть от того, имеет ли это смысл </li></ul>
    28. 28. Continual Service Assessment <ul><li>Поскольку главный приоритет ИТ-департамента – это стабильность, сервисы в среде эксплуатации не должны меняться </li></ul><ul><li>Н еобходимо постоянно оценивать сервис для подтверждения </li></ul><ul><ul><li>его высокого качества, </li></ul></ul><ul><ul><li>почти полного соответствия ожидаемому уровню, </li></ul></ul><ul><ul><li>и того, что прочие сервисы – существенно важнее </li></ul></ul>
    29. 29. Модель CSA
    30. 30. Для самостоятельного изучения: <ul><li>Роли </li></ul><ul><li>Метрики </li></ul><ul><li>Активности </li></ul>
    31. 31. Один серьезный слайд <ul><li>Сценарии развития ITSM в реальном мире </li></ul><ul><ul><li>Прогресс не остановить. Service Management – Service Manager’ ам! </li></ul></ul><ul><ul><li>Мы пойдем своим путем. Упростить – Понять – Принять. </li></ul></ul><ul><ul><li>Мы не пойдем. Нам ле [ а ] ниво. </li></ul></ul><ul><li>Ваш выбор? </li></ul>
    32. 32. Всё. <ul><li>Спасибо! </li></ul><ul><li>С 1 апреля!! </li></ul><ul><li>До новых встреч!!! </li></ul>

    ×