Введение в Реальный ITSM

Введение в Реальный ITSM
Роб Ингланд (The IT Skeptic)
Перевод Романа Журавлёва
Редактор Олег Скрынник
Ингланд, Р.
Введение в реальный ITSM / Роб Ингланд; Пер. с англ. - М.: Лайвбук, 2011. - 132 с.
ISBN 978-5-904584-05-4
Translated under license from Real IT Service Institute's DespoITSM
program (переведено по лицензии Института реального управления
информационными сервисами в рамках программы ДеспоITSM).
© Two Hills Ltd, 2008
© Издание на русском языке, перевод, оформление - ООО «Клеверикс»,
2011 www.cleverics.ru
Издательство LiveBook.
www.livebooks.ru
Все права защищены. Никакая часть этой публикации не может воспроизводиться, сохраняться, копироваться и
распространяться какими бы то ни было средствами - электронными, механическими, фотокопированием и любыми
иными - без предварительного письменного разрешения автора.
Эта книга не может быть продана, выдана или иным способом распространена в любой форме, отличной от
оригинального оформления, без предварительного разрешения автора.
Несмотря на то, что содержание и оформление книги было подготовлено и проверено тщательно и внимательно,
автор, издатель и переводчики не несут ответственности за последствия каких-либо ошибок или неточностей в
книге. Мы не даём никаких гарантий того, что следование рекомендациям, изложенным в книге, приведет к чему-то
хорошему (честно говоря, скорее наоборот). Эта книга предназначена только для развлечения.
Эта книга - для тех, кто работает в ИТ и для тех, для кого работают те, кто работает в ИТ.
Сервис менеджмент - последний писк моды в управлении ИТ, отсюда «ИТ Сервис
Менеджмент». Самое популярное описание ITSM - это ITIL®.
Эта книга не про ITIL. Честно. Real ITSM - это ироничный сатирический взгляд на то, во что
могут превратиться реальные практики ITSM, и чем они отличаются от идеализированных
представлений, описанных в ITIL, или COBIT, или ISO20000, или...
Как и «настоящее живое пиво», Real ITSM - подлинная, без прикрас, практика, не отягощенная
всякими маркетинговыми штучками, ароматизаторами, улучшителями и консервантами.
Шутя мы можем открыть и изучить некоторые нестыковки между идеальным миром, описанным
в умных книжках, и реальностью ИТ сервис менеджмента.
Об авторе
IT Skeptic - это псевдоним Роба Ингланда (Rob England), консультанта и комментатора в области
ИТ. Обладая двадцатилетним опытом совмещения бизнес-требований и ИТ-решений, десять из
них он занимается управлением ИТ-услугами. Он активно участвует в работе itSMF
(объединения профессионалов в области ITSM), ведет популярнейший блог (www.itskeptic.org) и
пишет статьи, являясь последовательным критиком несуразиц в мире ИТ, в особенности связанных с ITIL и CMDB. И ещё ему платят за скептицизм. Роб живет с женой и сыном в
маленьком доме в небольшой стране очень-очень далеко.
Обложка: передовой командный пункт на третьем уровне штаб-квартиры компании Two Hills
(фото автора).
Такую кружку можно купить здесь: http: //www.itskeptic.org/shop
Сообщество Real ITSM находится по
адресу www.realitsm.com
Real ITSM™, Realitsm™, CultlTSM™, BAPITSM™, EgoITSM™, FavorITSM™, DogmaITSM ™,
PragmaITSM™, ParasITSM™ и Core Practice™ - зарегистрированные торговые марки Two Hills
Ltd.
ITIL® - зарегистрированная торговая марка UK Office of Government Commerce («OGG»). Марка
ITIL® зарегистрирована также в патентном бюро США.
Эта книга - сатирическое развлекательное произведение, рассматривающее ITIL® как явление в
ИТ-отрасли. Она никак не связана и не является частью IT Infrastructure Library®.
Книга, её автор и переводчики не имеют никакого отношения к OGG или каким-либо другим
организациям, связанным с ITIL®.
Посвящается Брайану Джонсону и Полу
Вилкинсону, пионерам ITSM-юмора
(если такая штука вообще возможна).
2
Содержание
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Введение ............................................................................................................................................ 5
Реакция на сервис Service Reaction ............................................................................................... 17
Спрос на сервисы Service Demand ................................................................................................ 23
Приручение сервисов Service Taming ........................................................................................... 28
Пестование сервисов Service Nursing ........................................................................................... 32
Постоянная оценка сервисов CSA ................................................................................................ 39
Активности Real ITSM ................................................................................................................... 41
Роли Real ITSM ............................................................................................................................... 49
Метрики Real ITSM ........................................................................................................................ 52
Приложение: Примеры вопросов экзамена .............................................................................. 54
Предисловие
Английская шутка гласит, что пилоты, заходящие на посадку в Новой Зеландии, обращаются к
пассажирам с предложением перевести их часы на пятьдесят лет назад. Те, кто это придумал, не
знакомы с Робом Ингландом, который, как мне кажется (а моё мнение вы даже на чашку кофе
поменять не сможете), на несколько лет опередил всех в том, что касается склок, связанных с
управлением ИТ-сервисами. То есть в дискуссиях, конечно.
При чтении этой книги я был, несомненно, польщен посвящением, в котором мы с Полом
Вилкинсоном названы «пионерами ITSM- юмора», который мы назвали IhumourTSM. Название
не прижилось.
Потом я заметил, что в указателе мое имя оказалось прямо над «известным олухом». Надеюсь,
это тоже не приживется.
Я не буду мешать веселью, абстрагируя шутки, зато постараюсь нарушить новую схему
сертификации и подскажу ответы на самые трудные вопросы новых экзаменов. Вот они:
• Вопрос 1: да
• Вопрос 5: только когда мужа/жены нет дома
• Вопрос 14: кто это говорит?
• Вопрос 27: потому что перед выпуском в печать Сатанисты организовали добавление в
текст приложений про аутсорсинг.
Всегда хотел это сделать.
В завершение этой бесполезной заметки к книге, над которой я от души хохотал, я рекомендую
Робу обзавестись стальной каской попрочнее, потому что его сатира бьёт прямо в цель слишком часто и слишком точно.
Брайан Джонсон
Автор некоторых ITIL-вещиц.
3
Предисловие
Как и любая дурацкая затея, эта началась с малого и потом подросла.
Изначально планировалось по-быстрому написать небольшую книжку
и публиковать её по мере появления спроса, чтобы изучить сопутствующие трудности перед
публикацией «Того, что будет потом, Книги про ITIL». Это позволило бы сделать в новой книге
только новые ошибки.
Но эта книжка зажила собственной жизнью, обзавелась вебсайтом (www.realitsm.com), клубом
(EgoITSM) и глупыми картинками.
К слову, о картинках: говорят, что когда-то Нейл Янг только играл на гитаре и ничего не пел,
потому что смущался своего голоса. Пока не услышал Боба Дилана. Я чувствовал что-то
похожее в связи со своими рисунками, пока не увидел Дилберта Скотта Адамса. К сожалению,
Нейл Янг поёт лучше, чем я рисую.
Писать эту книгу было ужасно весело, и я надеюсь, вам будет весело её читать, как и войти в мир
Real ITSM. Добро пожаловать.
Несколько благодарностей:
Рецензентам: Терри Барвик (Terry Barwick), Чарльзу Бетцу (Charles Betz), Линдон Кристи
(Lyndon Christie), Велу Ингланд (Val England), Брайану Джонсону (Brian Johnson) и Полу
Вилкинсону (Paul Wilkinson).
Всем людям, которые в поте лица трудятся над созданием ITIL, и COBIT, и ISO20000, чтобы мне
было что критиковать.
И более всего - Ви и Джеку, за терпение, проявленное ко мне-сидящему-в-кабинете.
Спасибо.
Роб Ингланд
Пекеруа Бэй
Август 2008.
Настоящий Реальный ITSM
Предисловие к русскому изданию
Real ITSM - книжка о том, как устроено управление ИТ-услугами на самом деле. А устроено оно,
к сожалению, не очень хорошо. Так что «реальный» - вовсе не обязательно «настоящий», как
«нормальный» не обязательно значит «правильный, хороший». Просто так все делают. Ну или
большинство. (Примеры: реальная демократия, реальное здравоохранение, реальное страхование
автокаско. Никому ведь не приходит в голову назвать их настоящими.) Поэтому не надо ждать
от Real ITSM ничего хорошего.
Real ITSM - книжка сатирическая. В ней многим досталось - и тем, кто пишет умные книги вроде
ITIL®, и тем кто пытается слепо этим книгам следовать, и тем, кто строит на этом бизнес. При
этом примеры и практики, описанные здесь, настолько реальны, что и возразить-то на все эти
насмешки и издёвки особенно нечего. Многие читатели могли бы обидеться на автора, если бы
тут же не отвлекались на шпильки, адресованные другим, и не смеялись при этом до упаду.
Ловкий ход, ничего не скажешь.
Real ITSM - книжка для подготовленной аудитории. Многие шутки понятны только тем, кто
работает в области ITSM, читал ITIL®, сдавал экзамены и проходил (проводил) аудит по
ISO20000. И все это - не один раз. Некоторые - тем, кто знает английский язык1. Но большинство
- всем, кто работает в ИТ и так или иначе пострадал от проектов «внедрения ITSM». Собственно,
им книжка и адресована.
Мы испытали огромное удовольствие, когда читали и переводили «Введение в Real ITSM».
Очень надеемся, что и вам это понравится.
Команда Cleverics.
1
То есть австралийский и новозеландский жаргон, включая аббревиатуры.
4
1. Введение
Теория управления ИТ отлично подходит тем, у кого в избытке времени и денег.
Но что делать, если системы валятся, пользователи откровенно враждебны, бюджеты
сокращаются, персонал - неуправляем, а должность CIO - верный конец карьеры?
Вы применяете Real ITSM. Это единственный подход, учитывающий то, как ИТ работают в
реальном мире и адаптирующийся к этому миру с тем, чтобы минимально навредить ему и в то
же время обеспечить максимальную пользу для тех, кто вынужден этими ИТ управлять.
Недорогой, невредный, быстрый и простой, Real ITSM - это лучший подход для большинства
современных ИТ-департаментов.
Станьте реалистами.
1.1 Что такое Real ITSM?
Real ITSM - это свод знаний. Это означает, что Real ITSM собирает вместе все идеи, плохие и
хорошее, старые и новые, в единое хранилище для практиков ITSM.
Real ITSM - это подход к внедрению, он представляет проверенные общепринятые практики Real
ITSM.
Real ITSM отражает передовые идеи в области Real ITSM, обеспечивая новаторство, лидерство и
актуальность на многие годы вперед.
То, что между этими тремя утверждениями существует фундаментальное противоречие, не
ускользнуло от нашего внимания; но, поскольку для ITIL такое противоречие - не проблема, мы
не позволим ему нас смутить.
Сейчас Real ITSM только начинается. То, что вы держите в руках, - это Real ITSM 1.0, но мы
уверены, что Real ITSM станет сводом знаний более раскрученным, чем ITIL, более
скрупулезным, чем COBIT, боле полезным, чем MOF, более скучным, чем РМВОК и более
непонятным, чем CMMI.
В отличие от всех перечисленных, Real ITSM не содержит лучших практик, или хороших
практик, или общепринятых, или даже худших.
Real ITSM представляет реальные практики: управление ИТ сервисами, как оно происходит в
реальном мире2.
1.2 Принципы Real ITSM
Любой, кому довелось испытать удовлетворённое
спокойствие зрелой и стабильной ИТ-организации, будет
стремиться к таким условиям труда.
Такое теплое местечко можно организовать, принимая и
последовательно применяя принципы Real ITSM, известные
как Realitsm (произносится
«реалитсм», почти как
«релизм»)
Основные угрозы стабильности в ИТ - это изменения,
ответственность и сокращение расходов. Реалитсм
направлен на устранение этих угроз из ИТ-окружения в
интересах всех в ИТ. Гармоничная ИТ-среда требует
строгого соблюдения следующих принципов:
2
Реальные практики (Real Practice) похожи на основные практики (Core Practice), другую блестящую идею автора.
Основные практики - это минимум, необходимый для выполнения работы при удержании рисков ниже
определенного порога. См. www.corepractice.org.
Real ITSM не имеет связи, не является частью и вообще не имеет ничего общего с юридическим продуктом Real
Practice™ на www.realpractice.com. Real ITSM не имеет никаких отношений с законом и предпочитает, чтобы так
было и впредь.
5
•
•
•
•
•
•
обеспечьте стабильность среды эксплуатации
добейтесь максимальной приспособляемости к изменениям
повышайте вовлеченность через коллективное принятие решений
поддерживайте уверенность и оптимизм путем снижения групповой ответственности
повышайте прибыль и финансирование ИТ-департамента
повышайте выгоды и пользу для персонала ИТ.
1.3 Real ITSM против ITIL
ITIL описывает «лучшие практики3», идеализированную модель, к которой мы можем
стремиться. ITIL отлично подходит теоретикам, академикам, консультантам, ИТ-менеджерам и
всем остальным, так же оторванным от реальности.
Здесь внизу, в реальном мире, среди простых смертных, более распространена другая модель Real ITSM, описывающая реальные практики.
В Real ITSM есть свой жизненный цикл, активности, роли и
метрики, аналогичные ITIL'овским, но совершенно другие. Они
отличаются от тех, что описаны в ITIL, поскольку, не в пример
ITIL, должны быть совместимы с реальным, физическим
миром, населенным упрямыми, непредсказуемыми и, в общем,
бесполезными устройствами, именуемыми людьми.
Когда любая идеализированная модель встречается с людьми,
законы логики перестают действовать, и здравый смысл
вылетает в окно.
Когда подходы к ITSM проходят через эту реалитсмическую
трансформацию, получается Real ITSM. Большинство сводов
знаний ориентировано на процессы. Real ITSM ориентирован
на людей: мы понимаем, что всё происходящее на самом деле
зависит от них - их мотиваций, культуры, личных планов,
страхов и желаний.
1.4 Совмещение ИТ с бизнесом
Это понятие сейчас на пике моды. На самом деле, так было году этак в 2005, а по-настоящему
новая идея, необыкновенная и захватывающая - это «интеграция ИТ с бизнесом».
Это разумеется, нонсенс. ИТ - это часть бизнеса, кроме тех случаев, когда их отдали в
аутсорсинг (но бизнес, который это сделал, долго не протянет, так что мы здесь можем это не
учитывать).
Мы же не переживаем за совмещение логистики с бизнесом или за
интеграцию финансов. Отдел ИТ - просто ещё один отдел и должен
вести себя соответственно, что означает: защищать свои законные
права и расширять влияние.
Взгляните на любой отдел управления персоналом. Или маркетинга.
Никто всерьез не рассматривает мысль о том, что они действуют в
интересах всей организации. Вот и ИТ не следует. Если отдел ИТ
начинает работать на организацию, он очень скоро оказывается не у
дел.
По общему мнению, информационные технологии становятся
товарным ресурсом (см. знаменитую книгу Николаса Кара «IT Doesn't
Matter»). Большинство организаций не имеет отдела электричества.
ИТ запросто могут быть поглощены службой эксплуатации зданий.
Никто из айтишников не хочет закончить карьеру,
33
ITIL v3 скатился к «хорошим практикам»
6
нося серую униформу и используя карандаши, так что ИТ-отдел должен усердно работать, чтобы
предотвратить такую судьбу. Объединённые айтишники выстоят, интегрированные - падут.
1.5 Модель Real ITSM
Real ITSM состоит из:
•
безжизненного цикла, в котором сервис проходит от первичного непонимания до полной
запущенности
• набора выполняемых активностей
• ролей, размещаемых на визитках или игнорируемых
• метрик, используемых для искажения действительности
• полезных дополнений.
В отличие от ITIL, где слово «процесс» используется с
бесцеремонным пренебрежением в отношении любых
общепринятых определений процесса, Real ITSM
предпочитает говорить об «активностях».
Мы делаем это отчасти потому, что такое слово лучше
подходит по сути, а отчасти - чтобы оставить с носом
юристов OGC. Это означает, что концепция «четырех
П» (Персонал, Процессы, Продукты, Партнеры) больше
не работает. Real ITSM использует другую модель:
Народ - Активности - Хозяйство - Паразиты,
сокращенно «НАХП».
Активности Real ITSM выполняются на всех фазах
безжизненного цикла вне зависимости от сервисов. Сам
цикл - тоже просто модель Активности и от него не зависят.
1.6 Безжизненный цикл
Сервисы проходят через безжизненный цикл от непонимания до, как правило, ужасного конца.
Прохождение через этот цикл похоже на прохождение судна через Большой барьерный риф.
Цель Real ITSM - свести к минимуму число сервисов, выходящих в жизнь, и к максимуму время и подготовку персонала на этом пути.
В случаях, когда сервис всё же достигает пользователей, акценты меняются на
противоположные: сервис должен оставаться в живых как можно дольше, что обеспечит
финансовую отдачу и необходимый объём работы. Цель при этом остается прежней:
минимизация изменений.
Безжизненный цикл состоит из пяти областей, или доменов, или секций или фаз, или шагов:
Реакция на сервис
(Service Reaction)
Планирование и стратегии запрещены. Любые действия Real
ITSM - реакция на давление бизнеса.
Спроc на сервис
(Service Demand)
Создание сервисов - форма уступки в ответ на спрос со стороны
бизнеса.
Укрощение сервиса
(Service Taming)
Сервисы приходят неожиданно и без предупреждения. Наша
задача – взять их под контроль.
Пестование сервиса
(Service Nursing)
Связавшись с сервисом, следует сконцентрироваться на том,
чтобы он прожил как можно дольше, чтобы обеспечить
максимальную прибыль.
Постоянная оценка сервиса
(Continual Service
Assessment)
Руководство, консультанты и сотрудники, занятые измерением
и оценкой сервиса, должны чувствовать себя счастливыми.
7
Рис. 1-5. Real ITSM
1.7 Предоставление ценности
Причина, по которой проекты по внедрению ITIL оказываются такими дорогими и
неуспешными, состоит в том, что модель, навязываемая ITIL бесконечно далека от реальной
ежедневной работы. Поскольку Real ITSM гораздо ближе к реальности, Real ITSM можно
внедрить быстро и недорого.
Это также создает побочное преимущество, состоящее в том, что
изменения сводятся к минимуму. Внедрение Real ITSM меньше
влияет на текущую работу и на настроение персонала, а также на
его (персонала) текучку.
Пользователей тоже тревожат изменения. Им будет спокойнее
видеть, что ИТ-сервисы предоставляются точно так же, как и до
проекта внедрения Real ITSM.
Тем не менее, Real ITSM формализует существующую практику.
Он позволяет руководителям участвовать в выездных
мероприятиях и семинарах; переходить с должности на
должность; перестраивать организационную структуру и менять
порядок отчётности, а также выпускать любые количества
документов, плакатов и электронных писем. Все это делает
руководителей счастливыми и позволяет им сконцентрироваться на управлении организацией, а
также отвлекает их от работающих сотрудников.
В перспективе ИРУИС (Институт реального управления информационными сервисами, см.
далее) планирует организацию ежегодных конференций в Канкуне, Бали и Монако, со
множеством преимуществ для всех участников.
8
1.8 Организация
Real ITSM представлен Институтом реального управления информационными сервисами,
ИРУИС4. Институт располагается в Лондоне5. Членство открыто для всех вендоров,
консультантов, тренеров, экзаменаторов и издателей без исключения (кроме тех случаев, когда
вы нам не нравитесь).
Совет директоров ИРУИС избирается советом директоров ИРУИС, Кандидатов может
предлагать любой желающий. Для поддержки международного статуса заседания совета
организуются на курортах по всему миру.
ИРУИС и его представители получают доход с помощью Real ITSM, но эти поступления
полностью идут на покрытие расходов, текущие улучшения и продвижение реальных практик, а
также обеспечение финансовой состоятельности различных организаций.
ИРУИС управляет рядом специальных программ к вящей выгоде сообщества Real
ITSM6.
1.8.1 КультITSM / CultITSM
CultITSM - это программа ИРУИС, направленная на продвижение Real ITSM, в частности:
вебсайта, рассылок, мероприятий, а также продуктов и услуг ИРУИС и членов ИРУИС (в
особенности тех из них, кто спонсирует или рекламирует ИРУИС, и тех, кто исхитрился войти в
совет).
Вендоры всегда рады возможности продвижения своих решений с по мощью различных
подписок и неоплачиваемого труда добровольцев. ИРУИС и КультITSM предоставляют такую
возможность.
18.2 БиПITSM / BAPITSM
Бизнес и профессионалы ITSM (БиПITSM) - это программа регистрации для профессиональных
практиков Real ITSM. За небольшую плату профессионалы могут стать полностью
аккредитованными членами ИРИУС.
Членство контролируется и утверждается Институтом и доступно только лишь тем, кто оплатил
его.
Действующая аккредитация поддерживается путём демонстрации опыта и развития в области
Real ITSM и регулярной программой профессионального роста, включающей в себя участие в
веб-трансляциях, курсах и встречах Real ITSM.
1.8.3. ЭгоITSM / EgolTSM
Для тех, кто не может позволить себе БиПITSM, существует Эго ITSM,
открытый реестр профессионалов, практикующих Real ITSM.
Любой желающий может зарегистрироваться (тем более, что платить не надо), после чего
получить доступ к форуму ЭгоITSM, специальным скидками и чудесным рассылкам от
КультITSM.
Поскольку ИРУИС не подтверждает приведенную выше информацию и не гарантирует
подлинность и достоверность, а также поскольку мы не рекомендуем, не гарантируем и не
обещаем предоставление описанных услуг, явно или косвенно (там же реальные
профессионалы!), ценность регистрации - под большим вопросом. Но она наверняка не
повредит, разве что репутации регистрирующегося.
Очевидная осязаемая выгода - возможность распечатать замечательный бессмысленный
сертификат.
4
the Real IT Service Institute, or RITSI
Лондон. Танзания
6
Сообщество Real ITSM - это, разумеется, вендоры, консультанты, тренеры, экзаменаторы и издатели.
5
9
1.8.4 ПаразITSM / ParasITSM
ИРУИС отлично понимает взаимную ценность симбиотических отношений
индустрии и её аналитиков. Чем больше аналитики вкладывают в понимание чего-то, тем
больше они заинтересованы в широком продвижении этого «чего-то», каковое продвижение
обеспечит в будущем возврат сделанных вложений благодаря продаже накопленной экспертизы.
Именно поэтому программа ПаразITSM обеспечивает всестороннюю поддержку аналитиков:
•
•
•
•
•
•
быстрое ознакомление с Real ITSM, как правило - за ланчем, или «Хотите поговорить об
этом?»
примеры успешных внедрений из базы успешных внедрений
интервью с ведущими экспертами отрасли
шаблоны докладов для публикации (гарантируются уникальность и оригинальность)
перечень вендоров, ищущих обследования и аудита и таблицы рекомендованных цен
прайм-тайм для выступлений на всех конференциях.
1.8.5 ДогмаITSM/ DogmalTSM
Целостность реальных практик - важнейший принцип ИРУИС. Поэтому был нанят на
полставки неквалифицированный карьерный бюрократ для руководства текущим развитием
реальных практик в рамках программы ДогмаITSM.
Программа ДогмаITSM обеспечивает доведение основного содержания реальных практик до
совершенства путём организации регулярной (один раз в семь-десять лет) оценки и пересмотра.
Программа предполагает проведение тендеров для выявления наиболее знающих авторов. Чтобы
обеспечить глобальность подхода, авторов выдвигают вендоры из более, чем одной страны. См.
также «Соучастие в Real ITSM», стр. 15.
Кроме того, Догма ITSM утверждает Полезные дополнения, см. стр. 15.
1.8.6. ПрагмаITSM7 / PragmaITSM
Им понимают, что слушатели учебных курсов усваивают в лучшем случае четверть того, чему
их учат, и что такое обучение на порядок менее эффективно, чем реальная практика.
Поэтому Real ITSM использует учебные курсы только для желающих платить за них. Основной
же метод обучения базируется на программе ПрагмаITSM. В рамках этой программы реальные
практикующие эксперты Real ITSM демонстрируют свой опыт путем подробных рассказом о
нём. За небольшую плату этот опыт оценивается агентством по аккредитации ПрагмаTSM, и
квалификация подтверждается сертификатом.
См. также Квалификация Real ITSM, стр. 13
1.8.7 ФаворITSM/ FavorlTSM
Для того, чтобы упорядочить отрасль Real ITSM, а следовательно – и защитить целостность
ИРУИС и доверие общества к Real ITSM, ИРУИС сертифицирует пользователей, продукты и
услуги в рамках программы ФаворITSM8.
Другие подходы благополучно проигнорировали коммерческий потенциал такого рода
сертификации, отдав эту область на откуп различным грабительским организациям. ИРУИС не
намерен повторять эту ошибку, хотя в случае соответствующих предложений от
заинтересованных сторон мы, возможно, пересмотрим данный принцип.
Подробности - на стр.12, Соответствие Real ITSM.
7
ПрагмаITSM не имеет никакого отношения или сходства с замечательной компанией pragmITSM
(www.pragmitsm.com). Противоположности иногда мыслят одинаково. Real ITSM не занимается продажей
программного обеспечения и предпочитает, чтобы так было и впредь.
8
По-английски –FavorITSM (см. заголовок раздела). Вообще-то обычно терминология Real ITSM основана на языке
тех, кто этот язык изобрел. Но в данном случае FavorITSM смотрится гораздо симпатичнее, чем FavourITSM.
10
1.8.8 ДеспоITSM / DespoITSM
Как и другие авторские своды знаний, Real ITSM защищён законом об авторском праве. ИРУИС
тщательно защищает свою интеллектуальную собственность в рамках программы ДеспоITSM.
Эта программа (Нет! Хватит! Только не ПРОГРАММА!) обеспечивает защиту в следующих
случаях:
• некорректное использование защищаемых законом материалов
• использование наших торговых марок
• пародии и сатирические имитации Real ITSM
• неоплата счетов
• просроченные подписки
• задержка возврата книг в библиотеку ИРУИС.
Эта работа отдана в аутсорсинг компании «Агенство Лю и Стэна по сбору долгов и защите
интеллектуальной собственности». Лю и Стэн обладают потрясающей способностью
предотвращать долгие юридические споры и имеют многочисленные филиалы в разных странах.
1.9 Органы власти Real ITSM
В ITSM нет руководства, хотя и формируются определённые данные, интересующие
руководителей. В ИТ вообще нет руководства (хотя ИТ тоже формируют некоторые данные для
своих хозяев). Руководство осуществляют руководители, ни один из которых не работает в ИТ
(руководители вообще не работают). Следовательно, нет смысла осуждать руководство и в Real
ITSM, исключая руководство сообществом свода знаний Real ITSM.
В наши дни, когда слова «менеджмент» или «управление» обозначает вообще любую
деятельность, а слово «руководство» используется для того, для чего изначально предполагалось
слово «управление», непонятно, что следует называть «руководством Real ITSM». Поэтому и
RealITSM используются такие понятия, как «Правление» и «Владычество» (примечание: вообще,
это очень неправильно, когда король выносит мусор, а менеджеров называют «гуру». Что будет
дальше?)
И RealITSM нет единоличного правителя как такового. Здесь есть следующие органы власти:
• председатель совета директоров ИРУИС (Роб Ингланд)
• директор ИРУИС (Роб Ингланд)
• ведущий архитектор ДогмаITSM (Роб Ингланд)
• главный экзаменатор ПрагмаITSM (Роб Ингланд)
• ведущий оценщик ФаворITSM (Роб Ингланд)
• вебмастер (Роб Ингланд)
• агентства по аккредитации (Two Hills Ltd: директор - Роб Ингланд).
Таким образом, ответственность распределена между несколькими управляющими ролями, что
обеспечивает баланс сил.
1.10 Оценка
Поскольку Real ITSM в общем-то ничего не меняет, основные усилия практикующих его
специалистов будут направлены на оценку текущего состояния. Так как эти оценки будут
практически единственным материалом для консультантов, рекомендуется проводить их
ежемесячно - пока или деньги не кончатся, или консультанты не уйдут (см, Постоянная оценка
сервисов, стр. 39).
Терминология Real ITSM достаточно расплывчата, чтобы сделать измерения простыми и
понятными (см. «Соответствие Real ITSM», стр. 12).
В конце каждого раздела этой книги вы найдёте таблицу самооценки для вашего текущего
состояния. Её можно загрузить с сайта ИРУИС (www.realitsm.com), использовать для проведения
самооценки и сравнивать свои результаты с результатами других организаций, практикующих
Real ITSM.
11
1.10.1 Модель зрелости
Модель зрелости Real ITSM основана на СММ9. Оптимальный уровень зрелости - первый, хотя
нулевой тоже подходит. Коль скоро Real ITSM моделирует реальный мир, все активности Real
ITSM обычно выполняются (уровень 1). Когда департамент ИТ принимает решение о
прекращении какой-либо активности (снижение до уровня 0) в интересах упрощения и более
спокойной жизни - это обычно здравое решение. Ну а поскольку главные принципы Real ITSM это устойчивость к изменениям, гибкость перед лицом неотвратимых изменений и избегание
ответственности, попытки переместить активности на любой другой уровень зрелости
рассматриваются как непродуктивные и требуют корректирующих мер.
1.11 Соответствие
В отличие от некоторых других подходов, Real ITSM не недооценивает возможности и,
разумеется, важности сертификации организаций и продуктов на соответствие Real ITSM.
Чисто приходится слышать утверждения, что небрежно сформулированные подходы, вроде Real
ITSM или ITIL, слишком нечётки и могут быть вольно интерпретированы, а потому не могут
служить базой для сертификации соответствия. Простой анализ проблемы указывает на
ложность подобных рассуждений. Высокая степень свободы делает сертификацию на
соответствие проще, а не труднее. Так что программа ИРУИС ФавоpITSM выдаст, за небольшую
плату, сертификат соответствия любым продукту, организации или личности, которые:
• располагают деньгами
• убедят ИРУИС, что они, в самом деле, соответствуют.
ИРУИС осознает, что в определённых обстоятельствах эти строгие требования могут
несправедливо ограничить способность претендента получить сертификацию, поэтому
сертификация Real ITSM следует практике ISO 20000, позволяя кандидатам самим определять
границы проверяемой на соответствие области. Так компания может, например,
сертифицироваться только в рамках одной страны. Ну, или консультанты могут заказать
сертификацию своего костюма и/или ботинок, а не всех своих услуг целиком.
Предполагается, что сертифицированные организации (продукты, люди) всегда будут уточнять
границы сертифицированной области при указании любых ссылок на свои сертификаты.
Вообще-то, мы думаем, вы никогда не будете этого делать, но «предполагается» - отличное
слово, чтобы перенести на вас ответственность.
Для обеспечения этой деятельности на сайте www.realitsm.com можно найти опросник (для
вашего удобства в нём по умолчанию отмечены ответы «да»). Механизм предоставления
опросника и порядок оплаты можно найти там же, как и список аккредитованных организаций
(продуктов, людей).
9
СММ (Carnegie Mellon Model, позже переименованная в Capability Maturity Model, известна также как CMMI) - значимый
источник славы и прибыли университета Carnegie Mellon с того времени, как американская оборонка оплатила её (модели)
разработку. Чрезвычайно успешная модель, потому что чрезвычайно удобная во множестве случаев.
12
Никакая организация не может проводить сертификационную оценку или предлагать
альтернативные схемы сертификации на соответствие Real ITSM? не будучи аккредитована
ИРУИС (уже не за такую небольшую плату)10.
1.12 Уровни квалификации
Когда-то в будущем под эгидой программы ПрагмаITSM будет собрано Заседание по
Вступительным Экзаменам Real ITSM, ЗВЭРИ11 для разработки программы сертификации в
сотрудничестве с теми, кому это будет выгодно больше всех (обычная общепринятая практика).
Основная активность, подлежащая сертификации - это оценка. Также предполагается
сертифицировать консультирование, сбор требований, реорганизацию, выбор инструментария,
документацию, рекомендации и другие важные активности.
Предлагаемая схема квалификационной сертификации Real ITSM включает четыре уровня:
• база (другое название - чистилище)
• толкователь («на самом деле Real ITSM - это...»)
• эксперт
• реальный эксперт
За небольшую доплату успешно сдавшие экзамен получат сертификат, отпечатанный на
первоклассной бумаге, а также цветной значок. Цвет значков будет меняться по принципу
ротации каждые пять лет.
Квалификационная схема Real ITSM, как и экзамены, устанавливается официальным агентством
ИРУИС по аккредитации (Two Hills Ltd) в тесном сотрудничестве с Two Hills Ltd.
В интересах слушателей курсов, число участников каждого тренинга не должно превышать 30
человек (кроме on-line курсов, где число участников не ограничено). Курсы должны длиться не
меньше, чем предписано (в большинстве случаев - три часа), если только большинством
участников не определено иначе.
Курсы, тренинги и экзамены могут проводиться только по лицензии Two Hills Ltd. Лицензия
выдается за плату и предполагает статус ПжР (Пожизненная Рента) или РОЛ (Регулярная Оплата
Лицензии).12
10
Примечание: все платежи адресуются агентству ИРУИС по аккредитации, Two Hills Ltd.
11
Council of Real ITSM Matriculation Examiners, CRIME
12
Endless Income (EI) или Annuity Training Opportunity (ATO)
13
Квалификационная схема Real ITSM ясно отображена на следующем рисунке:
Обратите внимание на то, что эта структура соответствует Таксономии обучения Блума.13
Славшие «базу» немедленно награждаются сертификатами и получают подтвержденное право
участвовать в важных семинарах и совещаниях у себя в организациях и высокопрофессионально
проводить такое же обучение для других.
Но мере того, как кандидаты проходят каждый из модулей уровня «толкователь», они могут
рассчитывать на проектирование процессов, управление командами и, как предполагает
название, интерпретацию мудрости Real ITSM в соответствии с предпочтениями собственной
организации, а также основываясь на своих предрассудках, склонностях и прихотях.
По достижении статуса «эксперта» кандидат магически превращается и в эксперта, способного
давать стратегические рекомендации корпорациям и планировать многомиллионные ITSMпроекты, а также вести такого рода проекты к верному успешному завершению.
Это магическое превращение в ITSM-эксперта настолько важно, что требует специальной
церемонии посвящения. Каждый учебный центр может придумать собственный вариант
церемонии, включая туда - по желанию - различные тайные знаки, настольный теннис и
шашлык.
Квалификационная схема для наивысшего уровня - «реального Эксперта» - пока что не
согласована, и маловероятно, что когда-нибудь будет, ввиду экономической нецелесообразности
попыток его достичь.
Подняться до уровня реального эксперта на практике можно только (а) обретя бессмертие или
(б) будучи одним из создателей квалификационной схемы.
В отличие от многих других подходов, в Real ITSM список всех сертифицированных лиц
публикуется в центральной базе данных ПрагмаITSM на www.realitsm.com.
Сертификация Real ITSM - слишком ценная штука, чтобы позволять, кому попало заявлять об
обладании ею без законных оснований. Это было бы несправедливо по отношению к тем, кто
получил её упорным трудом (особенно с учётом церемонии посвящения).
Примечание: альтернативным образом квалификацию могут подтвердить те, кто обладает
большим практическим опытом в области Real ITSM. За небольшую плату они могут получить
сертификат без очереди. Мы ценим наших ветеранов.
13
Это такая штуковина, в ней четыре уровня. У нас - тоже четыре, так что «соответствует».
14
1.13 Полезные дополнения
Любые книги сторонних авторов, восхваляющие Real ITSM, могут получить аккредитацию
ИРУИС в рамках программы ДогмаITSM и статус реального полезного дополнения. После
уплаты административного взноса появятся ссылки на них на www.realitsm.com и постоянные
упоминания в книгах и презентациях.
Перечисленные ниже публикации уже сертифицированы как полезные дополнения к Real ITSM:
• реально ценная система обучения14 www.realvaluelearnino.com
• горячие тачки Гарри15 www.onlydroveonsundays.com
• Болгарский институт горизонтального народного танца16 www.LovelyBulgarianGirls.com
Более свежий список ищите на сайте Real ITSM (www.realitsm.com/DogmaITSM)
Кроме указанных полезных дополнений, следующие подходы демонстрируют синергию17 с Real
ITSM:
• ITSM From Hell
• COBIT
• CMMI
• ISO/IEC 20000
• ISO/IEC 15504
• ISO/IEC 10995:2008
• ну ладно... ITIL
1.14 Соучастие в Real ITSM
Есть, четыре способа принять участие в Real ITSM:
1. Быть автором.
Дождитесь следующего обновления Real ITSM (около одного раза в семь лет). Участвуйте в
тендере на право писать одну или более книг.
Окажитесь среди примерно дюжины финалистов. Посвятите год жизни написанию книги.
2. Знать автора.
Вливайтесь в тусовку уже сейчас. У вас есть около семи лет на то, чтобы угадать, кто выиграет
тендер в следующий раз и стать важной частью его (их) жизни и работы. Теперь убедите его
(их), что ваши идеи - лучше, чем его (их) собственные.
3. Свяжитесь с программой ДогмaITSМ и сообщите, что у вас есть, с чем соучаствовать.
Документированной процедуры подачи такой заявки не существует, как и специальной точки
контакта, но в ИРИУС сидят бюрократы, так что они покажутся вам открытыми и готовыми
14
Real Value Learning Systems
15
Harry’s Hot Autos
16
The Bulgarian Institute of Horizontal Folkdance
17
Мы тоже не знаем, что это значит.
15
помочь. Как только вам удастся привлечь их внимание, вы окажетесь в контакте с авторами
будущих версий. См. пункт 2.
4. Даже не пробуйте.
Примечание: организации или лица, твердо уверенные, что некий материал непременно следует
включить в Real ITSM, могут апеллировать к официальным архитекторам ИРУИС (Two Hills
Ltd), и те за небольшую плату вставят этот материал в следующую редакцию.
16
2. Реакция на сервис Service Reaction
Современный мир слишком динамичен, так что любое средне- или долгосрочное планирование
является бессмысленным.
Правительства, законы, директора, конкуренты, технологии, рецессии и причуды приходят и
уходят подобно капризам погоды. Как говорилось в старой военной поговорке, «планы обычно
погибают в первом бою». Стратегическое планирование полезно, как зонтик в разгар урагана.
Real ITSM понимает это и потому запрещает все виды стратегического планирования как
безответственное транжирство. Гораздо лучше прокладывать свой путь среди непредсказуемых
ветров перемен, сохраняя максимальную гибкость и независимость18.
2.1 Принципы Реакции на сервисы
В отличие от ITIL v3, где всем желающим предлагается стратегический подход, Real ITSM
полностью, совершенно, абсолютно реактивен. Как и стратегия сервисов (Service Strategy) в ITIL
v3, Реакция на сервис представляет собой эзотерическое знание, и не стоит с неё начинать
(аналогично, внедрение ITIL начиная со стратегии сервисов может привести к непрерывному
непрекращающемуся страданию). Поработайте над остальными четырьмя разделами
Безжизненного цикла, чтобы подойти к Реакции в достаточно бесчувственном состоянии.
Реакция на сервисы (далее - просто «Реакция») описывает основные принципы Realitsm'a.
•
•
•
•
•
•
Определите Максимальный период практического прогнозирования (МППП)19, обычно шесть месяцев. Ограничьте всё финансовое планирование этим периодом. Обратите
внимание, что бюджетное планирование может выходить за рамки МППП, и даже
выполняться на год вперед. Но не больше. Все последующие годы в бюджете должны
быть спланированы гипотетически, если не сказать вымышлены.
Недогружайте все ключевые ресурсы, чтобы обеспечить запас на случай капризов
руководства, сокращения бюджетов, массовых увольнений, слияний и других неприятных
неожиданностей. Применяйте это правило в отношении персонала, серверов, сетей, денег,
дискового пространства...
Следовательно, гасите в зародыше любые работы, направленные на оптимизацию,
рационализацию или консолидацию.
Документируйте минимум процедур (обычно - минимум, необходимый для сертификации
по ISO 9000), при этом не исполняйте ни одной. Повторяемые процедуры формируют
привычки, что подавляет в сотрудниках гибкость и творческое начало. Чем больше число
способов реализации процедуры, тем больше вероятность, что один из них будет работать
после катастрофического изменения. Это – дарвинизм20. Повторяемые процессы - как
искусственно выведенные сорта в сельском хозяйстве: весьма продуктивны в хорошие
годы, весьма уязвимы в периоды болезней, вредителей, непогоды и других волнений.
Глушите обратную связь. Любой инженер скажет вам, что непогашенная обратная связь
формирует опасные колебания. Отчёты и метрики должны содержать только
информацию, необходимую для назначения виновных, и быть достаточно устаревшими
для предотвращения неконтролируемых циклов обратной связи. Устраните ненужную
прозрачность.
Запретите постоянное улучшение. Если система признана минимально пригодной к
использованию, оставьте её в покое. Ей не так уж долго жить, так зачем вкладываться в
улучшение того, что обречено в ближайшей перспективе? Любое реальное изменение
должно быть основано на цикле братьев Райт: Предположение - Действие - Авария Ремонт21.
18
Прим. переводчика: «Вы пробовали зашвырнуть комара? Он не летит. Точнее, летит - но сам по себе. И плюёт на вас.
Поэтому надо быть лёгким и независимым". М. Жванецкий.
19
Maximum practical forecast period, MPFP
20
Лишь немногие мутации удачны, но это - цена, которую приходится платить.
Цикл назван в честь братьев Райт, сломавших немало самолетов до того, как им удалось поднять в воздух один из
них.
21
17
•
•
•
•
•
•
Подавляйте «инициативы из народа». Наверху наверняка втайне планируют что-то, что
сделает лучшие идеи бессмысленными и бесполезными, обычно - в период, когда
инвестиции достигли пика, а польза ещё не началась.
Проявляйте инициативу только в ответ на указания сверху. Сведите вложения к
минимуму, необходимому для предотвращения наказания. Этого как раз хватит, чтобы
создать оправдания, и это гораздо меньше, чем надо для получения какого-либо эффекта.
Это называется законом сохранения инвестиций и иллюстрируется трехцветной
штуковиной, известной как «Диаграмма Венна» в разных научных книжках.
Избегайте специализации. Обучение персонала сверх необходимого минимума - пустая
трата ресурсов. Лучше иметь много сотрудников, ориентирующихся в основных
системах, так как из-за возможных сокращений и перемещений состав департамента даже
в ближайшем будущем совершенно непредсказуем. Единственное исключение - тот
последний специалист, который ещё понимает ваши старые системы. Ни при каких
обстоятельствах не пытайтесь сформировать для него замену или дублера. Обучение
влетит в копеечку и не даст результатов, но главное - даже не в этом. Смерть или
увольнение этого специалиста - возможно, ваш единственный шанс толково обосновать
замену старой системы на современную, ибо старая, как правило, дешевле, надежнее и
эффективнее любой новой.
Принятие решений опасно для организации и отдельных сотрудников. Решения чаще
всего неверны. Их принятие надо или постараться переправить кому-нибудь, кто сидит
достаточно высоко, чтобы не волноваться и не понимать, или организовать коллективное
решение силами комитета, несводимого к кому-либо одному. Коллективное обсуждение
имеет важное преимущество: большинство решений забалтываются до состояния, в
котором уже не представляют угрозы.
Управляйте сервисами как активами. Их ценность определяется тем, какое
финансирование или прибыль они обеспечивают для ИТ-организации. Оценивая
ценность, не забудьте включить в расчёты одноразовые вливания, направленные на
аварийное восстановление или предотвращение публичного порицания, наряду с
текущими затратами. Самые дряхлые сервисы - самые ценные, так как требуют более
всего средств просто на поддержание жизни. Неизбежное устаревание сервисов повышает
их ценность: модернизации потребуют выделения финансирования, в то же время все
проводимые изменения - в ваших руках.
Ключевой принцип: все сервисы должны формировать максимум ценности для тех, кто
их внедряет. Выбирайте проекты, которые станут ценным дополнением к резюме и
помогут в поиске работы. Это обеспечит оптимальное участие персонала и поможет
преодолеть сопротивление изменениям. Преимущества, которые получат ваши
сотрудники, известны как возврат инвестиций, или ROI. Чтобы обеспечить максимальное
18
значение ROI, надо проводить регулярную оценку рынка труда. Это называется
«определять долю рынка»22.
2.2 Поставщик сервисов
Определите, к какому типу поставщиков сервисов относится ваша организация. В Real ITSM
есть три типа:
2.2.1 Тип I: Внутренний
Департамент ИТ входит в состав организации заказчика. Это положение может быть слишком
близким, чтобы оставаться комфортным: много прозрачности и «эффект курилки» - информация
получается неформально через обычные разговоры. В военное время это называется «болтун находка для шпиона».
С другой стороны, отношения обычно достаточно неопределенны, чтобы помочь вырабатывать
оправдания и перенаправлять нападки. Все виды «узких кругов», «семей» и «клубов по
интересам» могут быть использованы, когда вы оказались в сложном положении.
2.2.2 Тип II: Отсоединённый
ИТ-сервисы предоставляются отдельной бизнес-единицей. Если вам нравится эта модель, её
можно сформировать без усилий по отделению, простым внедрением ITSM, в частности - SLA.
Руководители обычно рады спихнуть с себя заботы об управлении ИТ, так что вы можете
договориться и о формализации выделения ИТ в самостоятельную единицу. Формализация
условий предоставления сервисов открывает простор для всевозможных толкований,
основанных на намеренном упрощении документов (все стремятся сделать SLA простыми).
Двусмысленности и лакуны открывают широкие возможности.
Несмотря на формальную самостоятельность, ИТ остается частью большой счастливой семьи,
так что у вас по-прежнему остается пространство для разного рода уверток, ухода от
ответственности и тому подобного.
2.2.3 Тип III: Удалённый
Поставщик сервисов - отдельная организация, работающая по контракту.
Может показаться, что это идеальный вариант, защищенный контрактом (с правильными
формулировками и без возможности пересмотра), но есть и обратная сторона. Внешней
организации очень немногое прощается, и её за многое несправедливо проклинают. При этом
возможностей управления ситуацией у вас немного: слишком много совещаний проходит без
вас.
С другой стороны, если для вас актуальна проблема изменчивости сервисов, нет лучшего
способа высечь текущую версию каталога сервисов в камне - раз и навсегда - чем отдать его в
аутсорсинг (см. стр. 27).
2.3 Сервисная амбразура23
Необходимо определить достаточно узкий набор критериев для пропуска сервисов.
22
23
Defining a market space.
Service Porthole
19
Сервисный диаметр24 определяет степень свободы, предоставляемой заказчикам при запросе
сервисов. Real ITSM работает над сокращением этой свободы.
Итоговая спецификация, через которую сервис должен пролезть
для того, чтобы быть принятым в эксплуатацию, известна как
Сервисная амбразура.
Для минимизации сервисного диаметра используются
следующие механизмы:
•
•
Оценка сервисов (Service Valuation): стоимость сервиса
может быть легко и значительно увеличена до значений,
заведомо неприемлемых для финансового директора.
План улучшения сервисов: хороший способ отвлечь
ресурсы, чтобы их не смогли привлечь к работе с новыми
сервисами.
2.4 Каскад сервисов
Один их наиболее важных документов в деле построения
отношений между ИТ и бизнесом - Каскад сервисов. Это
перечень предоставляемых сервисов с указанием их
взаимозависимостей. Чем больше зависимостей у сервиса,
тем больше условий придется выполнить заказчику для
доступа к сервису.
Оптимальное состояние - сервис, зависящий от других
сервисов или ресурсов, которые в свою очередь требуют
своих сервисов, и так далее - целый водопад каскадных
условий, обрушивающихся на пользователя (отсюда и
название).
Верно
организованный
каскад
сервисов
обеспечивает практически нулевую вероятность запуска
сервиса и работу. Правильно составленный контракт, в свою
очередь, позволяет ИТ продолжать выставлять счета и
получать по ним оплату.
Есть два основных вида каскада сервисов:
•
Каскад-буклет, или Каскад Чу-Ши25, где заказчикам обещаются разнообразные сервисы и
их уровни. Цветной, много шрифтов, красочная обложка.
• Технический каскад, где мы для собственных нужд документируем реальные сервисы.
Черно-белый, один шрифт, без обложки.
Естественно, описания сервисов в этих документах не имеют ничего общего, но этого никто не
заметит, поскольку названия у сервисов в обоих каскадах - одинаковые.
2.5 Ценность сервисов
Во время проектирования ценность сервисов оценивается по двум основным параметрам:
бестолковость26 и вариативность27.
24
Service Diameter (SD)
От китайского «Чу Ши» - верующий, доверчивый (ср. «Когда он стал буддийским монахом, его звали Да-цянъ, а
после того, как он вернулся к обычной мирской жизни, он назвал себя Да-цянъ Чу-ши или "Верующий Дацянь.») примечание переводчика
26
Futility
27
Variability
25
20
2.5.1 Бестолковость
Чем более бестолковые и пустые требования предъявляет пользователь, тем больше ресурсов (и
людей) можно посвятить их выполнению практически без всяких шансов предоставить-таки
запрошенный сервис. Поскольку у нас хватает ума не указывать на эту бестолковость на ранних
этапах безжизненного цикла, итоговый провал внедрения может быть совершенно справедливо
отнесён на счёт завышенных ожиданий пользователей. Они, конечно, могут что-то заподозрить,
но ничего не смогут доказать.
2.5.2 Вариативность
Чем выше вариативность возможных результатов в рамках требований пользователей, тем
большей свободой обладает ИТ в деле предоставления того, что возможно, а не того, что нужно.
Ну или в направлении работ по созданию сервиса в максимально бестолковое русло (см.
Бестолковость на предыдущей странице).
21
Проведите оценку своей организации на соответствие ключевым практикам реакции на сервис.
Запишите три балла за каждое соответствие и ещё один за каждый бонус. Собственно, можно
считать как угодно: это ваша оценка.
Практика
Баллы
Реальное финансовое планирование ограничено МППП (один год или меньше)
Бонус: Вы используете MS-Excel
Недозагрузка всех ключевых ресурсов обеспечивает резерв на всякий случай
Оптимизация, рационализация и консолидация запрещены
Документируется минимум процедур; ни одна не исполняется
Бонус: Вы используете MS-Excel
Отчеты и метрики содержат только информацию, необходимую для назначения
виновных, и достаточно устарели для предотвращения неконтролируемых циклов
обратной связи.
Бонус: Вы используете MS-Excel
Сотрудники знают базовые вещи о ключевых системах
Последние носители тайного знания об устаревших системах остаются
последними
Инициативы из народа гасятся в зародыше
Инициативы проявляются только в ответ на указания свыше, инвестиции сводятся
к минимуму, необходимому для предотвращения наказаний
Постоянное улучшение запрещено
Принятие решений передается наверх или выполняется коллегиально
Сервисы управляются как активы, и оцениваются на основе вкладов и прибыли
организации ИТ
Бонус: Вы используете MS-Excel
Все сервисы формируют достаточную ценность для тех, кто их внедряет
Определены достаточно жесткие критерии для допуска сервисов к жизни
Каскад сервисов описывает предоставляемые сервисы и их зависимости
Бонус: Вы используете MS-Excel
Вы добиваетесь максимальных бестолковости и вариативности всех сервисов
Всего баллов
22
3. Спрос на сервисы Service Demand
Несмотря на все наши усилия, заказчики настаивают на предоставлении им сервисов. Давление,
оказываемое на CIO со стороны других высоких руководителей, и необходимость продолжать
получать финансирование заставляют всё же обеспечить предоставление хоть каких-нибудь
услуг.
3.1 Проектирование сервиса
Реальный департамент ИТ понимает, что, несмотря на все
усилия, некоторые сервисы неизбежны, обычно по
политическим соображениям. В таких случаях мы применяем
три стратегических принципа (так называемые «Три П»).
3.1.1 Проектирование отказов
Где возможно, сделайте отказ от сервиса частью проекта.
Для этого есть много средств. Например,
• Поощрение двусмысленных требований к сервисам. Впоследствии измерения покажут,
что требования выполнены полностью (даже при полной неудовлетворенности
пользователей).
• Лоббирование неприемлемо дорогих опций при согласовании требований.
• Склонение пользователей к политически неприемлемым решениям.
• Формирование двух (и более) мощных пользовательских групп, формирующих
взаимоисключающие требования.
• Предоставление пользователям возможности менять свои требования в любой момент.
• Максимально возможное расширение границ проекта. Он должен либо схлопнуться под
собственной тяжестью, либо отодвинуть срок получения результата туда, где он будет
уже никому не интересен.
• Пренебрежение максимальным числом важных аспектов проектирования.
• Выбор технического решения, несовместимого со всей имеющейся инфраструктурой.
• Выбор неподтвержденных, сырых или - лучше всего - несуществующих технологий и
решений. Вендоры предоставят вам их в избытке.
3.1.2 Пролонгация
Индустрия ИТ создала множество эффективных способов продления проектов, все здесь и не
перечислить. Вот лишь некоторые, наиболее популярные:
• семинары, собрания и совещания заинтересованных сторон. См. Управление спросом,
стр. 42.
• расширение границ (см. Проектирование отказов, стр. 23)
• привлечение внешних консультантов (для получения наилучшего эффекта - на почасовой
основе)
• отвлечение ресурсов на «более приоритетные задачи».
3.1.3 Перевод (Перенос)
Ни один проект не заканчивается, как было задумано. Если действовать аккуратно, результат
может оказаться гораздо ближе к тому, чтобы соответствовать требованиям департамента ИТ.
• Архитекторы, специалисты по эксплуатации и внешние подрядчики должны иметь
возможность изменения решений, принятых при проектировании в сторону, удобную для
ИТ- команды или удачно дополняющую резюме.
• По мере построения сервиса, избавляйтесь от значимых его частей как от неоправданно
дорогих или недостижимых в поставленные сроки - особенно при приближении
окончания проекта (см. Пролонгация, выше).
• Используйте оставшиеся части в качестве «функциональных эквивалентов».
23
При проектировании сервисов важно помнить о таком показателе, как Совокупная стоимость
владения, ССВ (ТСО). Её, разумеется, следует максимизировать для обеспечения повышения
финансирования департамента ИТ.
3.2 SLA28
Service Level Argument (SLA) - документ, определяющий целевые
характеристики сервисов, к достижению которых будет стремиться ИТдепартамент. И тем самым - значения, которые должен принимать бизнес.
Здорово, если удается согласовать эти значения с бизнесом. Если нет - SLA
носит односторонний характер.
Наличие формального соглашения помогает поддерживать разделение ИТ и
бизнеса. Излишняя близость может привести к командной работе, что вовсе
не в интересах ИТ-департамента. SLA помогает поддерживать
состязательность.
Если в SLA чётко определены цели (например, 95% доступности), ИТ может
ограничить расходы таким образом, чтобы эти значения превышались как
можно реже, тем самым оптимизируя использование ресурсов. Большинство
организаций действует в условиях жёстких ресурсных ограничений, так что
будет нетрудно договориться о том, что недостижение установленных целей не должно мости к
наказаниям. Разумеется, ИТ-департамент делает всё возможное в тех рамках, которые для него
установлены, а заодно - в тех, которые он сам установил.
Как правило, возможности ИТ по части измерения качества сервисов ограничены, а у заказчиков
их вовсе нет. Поэтому результаты измерений обычно основаны на экспертной оценке.
Погрешность при проведении такой оценки стоит делать в лучшую сторону, что поможет
поддерживать дух сотрудников ИТ и не расстраивать пользователей.
Общей практикой являются регулярные споры с заказчиками о содержании SLA.
3.3 Доступность
При проектировании сервисов следует обеспечить
минимальный уровень доступности, который готовы
терпеть заказчики.
Верно составленные SLA вообще-то не содержат
обязательств, которые надо выполнять, но для того, чтобы
минимизировать
необходимость
управления
пользователями (User Management) в дальнейшем, надо
устанавливать ожидания на как можно более низком
уровне.
Режим предоставления сервисов 24x7 предпочтительнее,
чем ограниченные часы работы. 24x7 - это возможность
включить оплату сверхурочных в операционный бюджет,
что не мешает обосновать технологические перерывы, например, в обеденное время по
вторникам. Это также более надёжная инфраструктура, то есть более современные решения для
резервирования и восстановления, то есть более сложное внедрение и больше внешней
поддержки, то есть больше работы для вендоров, то есть больше приглашений на конференции.
С доступностью тесно связана мощность. Установленные пределы мощности обычно, так или
иначе, нарушаются под действием каких-нибудь непредсказуемых событий, так что
планирование и мониторинг производительности - вполне бессмысленное занятие. Кроме того,
нехватка мощности ведет к кризису, что позволяет быстрее и легче получить финансирование
обновления инфраструктуры.
См. также Кризис-менеджер, стр. 49.
28
Service Level Arguments, или Обоснования уровня сервиса. Аббревиатура ОУС не прижилась.
24
3.4 Аварии
Управление ИТ-авариями (IT Discontinuity, ИТ-прерывность) занимается сопровождением
систем во время катастроф. Аварии - необходимая часть управления ИТ: только в эти периоды
мы получаем достаточно внимания и средств, чтобы поддерживать рост и развитие
инфраструктуры.
Если авария достаточно разрушительна, даже простейшие действия по восстановлению заслужат
благодарность пользователей и все увидят, как ИТ старается восстановить уровень сервиса,
подобный тому, что был до катастрофы.
Большинство аварий происходят самостоятельно, и лучшая стратегия и работе с ними - ждать
начала. Это не отменяет возможности проектировать сервисы с учетом вероятности аварии в
течение определенного срока работы.
Аварии непредсказуемы по определению, так что планирование и тренинги не имеют смысла,
если только давление со стороны аудиторов не становится чрезмерным.
3.5 Безопасность
Системы безопасности существуют для того, чтобы заставить честных людей упорнее трудиться.
Они возлагают дополнительное бремя поддержки на ИТ, а также мешают сотрудникам,
пытающимся решить проблемы или удовлетворить свое любопытство.
Управление безопасностью должно инициироваться аудиторами. Минимизируйте вложения в
инфраструктуру безопасности, занимайтесь ею только под угрозой потери сертификации или
провала аудита. Это называется «управлять угрозами».
Нарушения безопасности влияют на репутацию ИТ, а самые серьезные могут негативно
сказаться на бюджете следующего года, поэтому полезно время от времени проводить аудиты.
Это помогает предотвратить потери бюджетирования, и поэтому называется превентивными
мерами безопасности. Аудиты лучше проводить силами ИТ- департамента, иначе некоторые
случайные выявления могут перевесить плюсы от проведения аудита.
25
3.6 Управление вендорами
Обычно вендоры хорошо справляются с управлением ИТ- департаментами, и их управление
почти не требует вмешательства ИТ.
Основные сложности возникают, когда персонал начинает ссориться за право быть контактным
лицом при общении с вендором. Особенно эта роль привлекательна для тех, кто любит
настольные игрушки, качественные рубашки-поло и ветровки, а также путешествия. В таком
случае может помочь регулярная ротация, а если она становится
слишком сложной,
руководители должны узурпировать эту роль.
В целях оптимизации управления вендорами полезно сделаться референтной площадкой. Это
даст вам следующие преимущества:
•
Любовь и внимание. Они требуют больше ресурсов вендора и достаются не всем
клиентам. Станьте одним из немногих.
• Слава. Вендоры ославят вас как героя в глянцевых брошюрах,
рекламных материалах, статьях, а лучше всего - в презентациях
на конференциях. Они разместят фото вашего CIO в
полностраничных рекламных публикациях в журналах, где их
увидят другие CIO, а потом подарят ему плакатную версию
этой рекламы в рамке.
• Конференции.
Внимательное
изучение
референтных
площадок, чьи CIO ездили в теплые страны на всемирные
конференции вендоров за счет вендоров в качестве
представителей заказчика может принести интересные
результаты. Особенно хорошо это работает с CIO за пару лет
до пенсии: примените любовь и славу, а когда они выйдут на
пенсию - наймите их в качестве всемирного ключевого гуруспикера для международных конференций в экзотических
местах.
• Слава. Вендоры ославят вас как героя в глянцевых брошюрах,
рекламных материалах, статьях, а лучше всего - в презентациях
на конференциях. Они разместят фото вашего CIO в
Рис. 3-5. Цепочка
полностраничных рекламных публикациях в журналах, где их
добавленной
стоимости
увидят другие CIO, а потом подарят ему плакатную версию
этой рекламы в рамке.
• Конференции. Внимательное изучение референтных площадок, чьи CIO ездили в теплые
страны на всемирные конференции вендоров за счет вендоров в качестве представителей
заказчика может принести интересные результаты. Особенно хорошо это работает с CIO
за пару лет до пенсии: примените любовь и славу, а когда они выйдут на пенсию наймите их в качестве всемирного ключевого гуру-спикера для международных
конференций в экзотических местах.
• Праздники. Перед лицом поражения празднуйте победу. Это старая английская военная
тактика на случай столкновения с неодолимым сопротивлением партизан: вернуться
домой и организовать парад победы. Незачем признавать, что полу-миллионный проект
провалился, если можно выкрутиться при громкой поддержке вендора. Расскажите всем,
как он успешен, и по прошествии некоторого времени даже ваши собственные
сотрудники начнут в это верить, особенно если их тоже начнут приглашать на
конференции в тёплые страны.
26
3.7 Аутсорсинг
Аутсорсинг часто негативно воспринимается айтишниками, хотя на самом деле это выгодное и
ценное явление, которое в определённых случаях стоит поддерживать.
Среди преимуществ аутсорсинга:
•
рациональность: аутсорсинг позволяет сотрудникам перейти в более крупную
организацию без необходимости поиска работы
• гибкость: перейдя в аутсорсинговую компанию, сотрудники получают более широкий
выбор технологий и платформ для работы
• стабильность: для тех, кто остался, аутсорсинг приносит стабильность. Изменения
становятся дорогими, сложными и медленными
• обучение: аутсорсинговые компании вынуждены демонстрировать более высокий
уровень компетенции, чем заказчики, поэтому та часть резюме, которая посвящена
сертификации, растет у их сотрудников существенно быстрее, чем раньше
• сокращения: те сотрудники, которые настолько неэффективны, что не были взяты в
аутсорсинговую компанию, по крайней мере получают выходное пособие и более
красивую строчку в резюме, чем просто «уволен»
• пенсия: те сотрудники, которые достигли пенсионного возраста, должны принимать
аутсорсинг и последующее сокращение как способ максимизации пенсионных
накоплений
• ответственность: помимо всех прочих плюсов, аутсорсинг - чрезвычайно эффективный
способ переноса ответственности с ИТ-организации на другую компанию
Оцените свою организацию на соответствие ключевым практикам управления спросом. Три очка
за каждое соответствие и одно за каждый бонус.
Практика
Баллы
Итог со страницы 22
Проектирование отказов
Затягивание поставки новых сервисов
Корректировка ИТ сервисов для большего соответствия требованиям ИТ
Формальные SLA и периодические споры с заказчиками о них
Бонус: Вы используете MS-Excel
Планирование и мониторинг производительности воспринимаются как
бесполезные
Проектирование сервисов с учетом минимального приемлемого для заказчиков
уровня доступности
Ожидание аварий и/или проектирование требуемой аварийности в течение
определенного периода времени
Отсутствие планирования и тренировок на случай аварий до тех пор, пока
давление аудиторов не станет невыносимым
Минимизация инвестиций в инфраструктуру безопасности, если только это не
ведет к утрате соответствия или провалу аудита
Бонус: Ожидание утраты или провала
Случайные аудиты силами ИТ
Система назначения контактных лиц для общения с вендорами
Бонус: Система ротации, позволяющая делиться благами
Стремление стать референтной площадкой
Поощрение аутсорсинга, когда это уместно
Итого
27
4. Приручение сервисов Service Taming
В том маловероятном случае, когда сервисы таки добираются до внедрения в продуктивную
среду, задача ИТ-департамента - обеспечить их внедрение с минимальным влиянием на
существующую инфраструктуру ИТ.
Это достигается с помощью:
• откладывания внедрения
• подгонки сервиса под существующие платформы и процессы
• снижения ожиданий пользователей до уровня, который практически уже достигнут
• минимизации стоимости и влияния тестирования и развёртывания.
Любые средства контроля и управления являются бонусом.
4.1 Захват, маркировка и релиз
Основная функция Приручения сервисов - Захват,
Маркировка и Релиз (также известные как 3 «П»: Поймать,
Промаркировать, Передать).
Первое, что служба эксплуатации услышит о новом
сервисе, это обычно запрос на внедрение, требующий
передачи сервиса в эксплуатацию, то есть сервис мелькает
в Сервисной амбразуре. Иногда это новость для всего ИТ,
но уж служба эксплуатации однозначно слышит о новом
сервисе впервые. Это называется Захват сервиса. Он дает
эксплуатационщикам возможность для первого знакомства
с сервисом.
Персонал службы эксплуатации должен иметь наготове
убедительные причины отказаться от нового сервиса. Это
называется готовностью эксплуатации29.
К сожалению, на этом этапе большинство сервисов имеют
непреодолимое ускорение, и все, что служба эксплуатации
может сделать - это дать сервису собственное имя
(Маркировка) и снять с себя ответственность за его
дальнейшее существование (Релиз).
Имя, присваиваемое сервису, основывается на терминологии, понятно» только ИТ - например,
используется сетевое имя сервера, на котором сервис вертится.
Цель Маркировки - обеспечить безопасность и конфиденциальность коммуникаций в службе
эксплуатации. Персонал эксплуатации должен быть обучен забывать все прочие имена, данные
сервисам.
Если вы любите что- то Поскольку сервис был спроектирован без каких-либо средств
отпустите его. Если оно
мониторинга и метрик, служба эксплуатации отпускает его в
вернется к вам, значит оно
продуктивную среду, в дикий опасный мир, где он будет жить, и
было вашим. Если нет,
развиваться в основном без её участия и внимания.
значит никогда и не было
Это снижает нагрузку на системы и высвобождает время сотрудников для
переконфигурирования устройств, изучения новых технологий и выступлений на конференциях
вендоров.
29
Operation Readiness
28
4.2 Изменения
Не делайте этого.
Если у вас нет иного выхода, кроме как нарушить это правило,
тщательный контроль над изменениями необходим для того, чтобы
обеспечить адекватное замедление их проведения.
Это
та
область,
где
является
уместным
скрупулезное
документирование, также как и оценка всеми заинтересованными
сторонами и тщательное взвешенное принятие решений на всех
уровнях.
См. также Кризис-менеджер, стр. 49.
4.3 Хозяйство
Менеджеры Real ITSM управляют Хозяйством, известным также как
«Активы» или «Конфигурации». Все Хозяйство должно быть на
учёте, кроме того, которое не учитывается. Основная работа по
Хозяйству включает:
4.3.1 Перепись
Начальство или аудиторы периодически запрашивают список Хозяйства. Поскольку их
требования абсолютно случайны и непредсказуемы, лучший способ работы - реагировать по
мере поступления запросов, выделяя персонал для проведения переписи.
Это называется «обработка по запросу30». Средство автоматизации - Excel.
4.3.2 Использование
Византийская сложность современной ИТ-инфраструктуры означает, что единственные
устройства, способные проконтролировать влияние изменения или сбоя какого-то компонента,
это опять люди. Вендоры утверждают, что существует ПО, обладающее этой магической
способностью, но только люди могут понять, что означает сбой одного из web-серверов в ферме
со сбалансированной нагрузкой, поддерживающей UDDI и предоставляющей общую
функциональность для четырёх приложений. Вам нужна CMDB по имени Сью. Сделайте так,
чтобы это могли сделать несколько человек и постарайтесь, чтобы они были счастливы.
Пусть вы внедрите самый супер-пупер продвинутый искусственный интеллект для анализа
концептуальных структур данных, рано или поздно эта штука сморозит какую-нибудь страшную
глупость. И все опять будут бегать к живому эксперту, чтобы перепроверить её заявления.
4.3.3 Построение CMDB
Мы в ней не нуждаемся, но должны её иметь. У всех ведь есть. И в
книгах так написано. Эта часть Real ITSM, наиболее подверженная
влиянию Чрезмерной Технической Скрупулезности31 (описанной
далее, см. Категоризация).
Лучшая стратегия - построить собственную CMDB. Проект
успешно продлится несколько лет, в течение которых вы будете
проектировать,
моделировать
данные,
программировать,
интегрировать, строить отчёты, что известно как 3 «П»
(Программирование, Проектирование, Построение).
Другая лучшая стратегия - купить готовую CMDB. Разумеется,
никто не может продать вам её. CMDB это абстрактное понятие,
вроде святости или честности.
То, что нам пытаются всучить вендоры, это базы активов с
30
31
On-demand processing
Excessive Technical Fastidiousness, or ETF
29
прикрученными звоночками, или средства мониторинга сети со свистками, или средства
управления десктопами, на которые подвешены плюшевые игральные кости. Это означает, что
вы ввязываетесь в проект по кастомизации, сравнимый по масштабам с построением и
развёртыванием собственной CMDB.
А потом начинается увлекательное упражнение по заполнению базы. Если вы построили модель
данных, которая достаточно широка и детальна (а к этому все и приходят), вы можете на годы
загрузить не-скольких своих сотрудников интересной работой по поиску, загрузке, маркировке и
взаимосвязи всего этого Хозяйства.
В любом случае, планируйте внедрение полномасштабного решения с самого начала: поэтапное
внедрение может привести к завершению проекта.
4.4 Знания
Основой всех денежных и трудовых затрат в Real ITSM является Бездонная Система Управления
Знаниями, BKMS32. Эта система содержит не только данные об ИТ-объектах, которые нам
случилось зарегистрировать, но также:
•
•
статистику загрузки автостоянки
истории болезни и личные дела пользователей (полезно при общении с проблемными
пользователями)
• результаты спортивных матчей в реальном времени (ясно зачем)
• данные о росте и смертности офисных растений
• данные о транзакциях в системах, выведенных из эксплуатации (на всякий случай)
• данные о площадях и объёмах офисных помещений и участков в залах общей работы
• данные об удовлетворенности поставщиков
• книгу рекордов Гиннеса
..и любые, в общем, данные, которые можно найти, независимо от их связи с сервисами.
Все данные маркируются назначаемыми вручную семнадцатизначными идентификаторами,
взаимосвязанными n-мерной системой связей (с кастомизированным ПО графического поиска и
отображения).
Самая рациональная BKMS использует структуру хранения данных ПМНЧ (WMRN)33.
Такой проект обеспечит непрерывно растущее финансирование, максимальную загрузку
персонала и высокий уровень удовлетворённости поставщиков.
32
Bottomless Knowledge Management System. Опять же, аббревиатура БСУЗ не прижилась.
Пишем Много Не Читаем, или Write Many Read Never, не путать с Write Once Read Many. Простейший пример
WMRN - неподключенный провод.
33
30
4.5 Культура
Без сомнения, главная причина провалов внедрения сервисов – не способность понять культуру
персонала ИТ.
ИТ-культура - это сплав спортивных результатов, ТВ-шоу, теорий заговора, злобных сплетен,
рассуждений о старых технологиях, жажды новых технологий, личной жизни знаменитостей,
планов на отпуск и здоровья детей. Её предельно просто понять, и Real ITSM не видит в этом
проблемы.
4.6 Тестирование
По слухам, есть организации, в которых тестирование выполняют специальные люди, не
участвующие в разработке, но свидетельств такой практики слишком мало, чтобы считать её
частью Real ITSM.
Тестирование лучше всего выполнят те, кто разрабатывал, ведь именно они лучше всех
понимают тестируемое. Выделенные тестировщики могут придумать множество избыточных
сценариев, что затянет фазу внедрения. Гораздо рациональнее выполнять все тесты внутри
команды разработчиков.
Оцените вашу организацию на соответствие ключевым практикам приручения сервисов. Три
очка за каждое соответствие, одно за каждый бонус.
Практика
Баллы
Итог со страницы 27
Захват все сервисов, идущих в продуктив
Бонус: Вы используете Excel
Персонал эксплуатации имеет подготовленные основания отказаться от новых
сервисов
Сервисы маркируются и именуются с использованием сугубо специфической ИТтерминологии
Бонус: Вы используете сетевые адреса или номера счетов
Новые сервисы отпускаются в эксплуатацию без дополнительной информации и
оповещений
Изменения минимизируются и замедляются
Бонус: Вы не проводите изменений
Все хозяйство учитывается, кроме тех случаев, когда учет не ведется
Бонус: Вы используете Access
Запросы информации о Хозяйстве выполняются по требованию
Бонус: Вы используете Excel
Используется живая CMDB...
Бонус: ... ПО имени Сью
Идет проект по построению или внедрению ПО CMDB
Бонус: Вы не используете поэтапный подход
Используется BKMS
Бонус: Вы используете концепцию WMRN
Культура игнорируется
Все тестирование выполняется в рамках разработки
Итого
31
5. Пестование сервисов Service Nursing
Стараниями проектировщиков, разработчиков и специалистов по развёртыванию, когда сервис
оказывается в продуктивной среде, он почти наверняка нестабилен, неуправляем и бесполезен.
Признавая, что сервис таки сумел - несмотря на все наши усилия - пробиться в жизнь, мы
должны сделать всё возможное, чтобы он прожил как можно дольше при минимуме инвестиций,
а значит - максимуме отдачи для департамента.
Функции Пестования сервисов:
•
•
•
•
минимизация негативного влияния на департамент
переназначение или размывание ответственности
снижение ущерба репутации
снижение активности пользователей до приемлемого уровня.
5.1 Проблемы
Остается загадкой, почему проблемы - та область, которой традиционно пренебрегают при
управлении сервисами. Ведь для их регистрации есть специальное место в любом ПО
автоматизации ITSM, стоящем своих денег.
Решение проблем дает возможность умникам из ИТ делать чтото помимо постоянной перенастройки и перемещения
Хозяйства. И делает пользователей счастливыми. То есть это
обоюдовыгодное решение.
Real ITSM считает проблемы одной из важнейших областей
пестования сервисов.
Проблемы слишком важны, чтобы внедрять управление
проблемами. Как только у вас появится процесс - с владельцем,
процедурами, записями, совещаниями, - все тут же смогут
снова расслабиться и перестанут обращать на проблемы
внимание. Просто решайте их.
Основная сложность, связанная с проблемами - дилемма
важности/срочности (см. рисунок ниже). Они важные, но редко
достаточно срочные, чтобы отвлекаться от непрерывно бомбардирующих нас инцидентов.
5.2 Телефон
Основное средство мониторинга в Real ITSM - это телефон.
Это устройство чрезвычайно чувствительно к любому
прерыванию сервисов и трезвонит в течение времени, прямо
пропорционального важности сервисов для пользователей.
Кроме того, телефон помогает Service Desk с высокой
точностью определять влияние и требуемое время
восстановления.
Таким образом, телефон делает ненужными все средства
управления сервисами, мониторинга событий, оповещения,
каталоги услуг и прочие излишества, используемые другими
подходами в области ITSM.
Он дёшев во внедрении, использует высоконадёжные
системы, имеет высокую доступность, не требует
администрирования, а его сопровождение и обслуживание
отданы на аутсорсинг.
Это настоящий шедевр в мире ИТ-оборудования.
32
5.3 Service Desk
Service Desk - важная часть пестования сервисов. Его можно
рассматривать
как
вспомогательную
функциональность
телефона.
Как любая система мониторинга, телефон, к сожалению, страдает
от высокого уровня шумов.
Service Desk отфильтровывает эти шумы (жалобы, обратную
связь, призывы о помощи...), оставляя полезную информацию о
доступности и возникающих проблемах.
Service Desk также выступает в роли буфера, защищающего
департамент ИТ от остальной организации (см. Управление
пользователями, стр. 41).
Service Desk состоит из трёх компонентов:
5.3.1 Люди
Постарайтесь найти таких, которые в самом деле любят других
людей. Также пригодится трехзначный IQ.
Подходящих кандидатов можно найти в туриндустрии: они
вежливы и любезны, умеют работать быстро, и любой, кто в
состоянии работать с системами бронирования вроде Galileo или
Magellan, имеет достаточно навыков в области ИТ.
5.3.2 Программное обеспечение
Единственное место в ITIL, где описаны требования к ПО, - это
место, и котором ПО абсолютно бесполезно, то есть CMDB. Real ITSM понимает, что
единственное место, где софт имеет значение, — это Service Desk.
Если вы можете хранить в одном месте людей, контакты, запросы, инциденты, проблемы,
изменения и активы, да ещё и контролировать передачу ответственности за них (то есть
горизонтальную и вертикальную эскалацию), а также хранить и группировать музыку из
Интернета, значит, вы получили то, что нужно для реального управления сервисами. Для всего
остального используйте Excel или телефон.
5.3.3 Правила, процедуры, оповещения
Они падают на персонал Service Desk подобно дождю.
Здесь важно заметить, что электронная почта - это не способ коммуникации. То же относится к
сетевым папкам, порталам, системам документооборота, базам знаний и тому подобному.
Коммуникации не могут быть односторонними.
Реальные коммуникации используют двойное подтверждение. Наиболее эффективным образом
эта техника работает в старомодном способе, известном как «разговор».
Регулярные встречи и совещания сотрудников, общие обсуждения - неё это необходимо для
успешного поддержания дистанции между Service desk и бизнесом.
33
5.4 Запросы
Real ITSM полагает все запросы от пользователей Запросами34.
После необходимых уточнений реальные запросы могут быть
классифицированы как35:
• инцидент: инцидент определяется как незапланированное
прерывание нормальной работы ИТ или снижение качества
с точки зрения ИТ.
• значительный (Major) инцидент характеризуется риском
того, что о нём услышат члены совета директоров или того,
что о нём будет написано в газетах. См. Управление
ущербом.
• запрос на изменение: некоторые организации позволяют
пользователям инициировать изменения напрямую, другие
создают специальные формы для их фильтрации - например,
запросы. Real ITSM рекомендует второй вариант как ещё
один способ отсрочить изменения.
• предложения: Service Desk может быть интерфейсом к
управлению портфелем проектов в той его части, которая
работает со спросом. Это можно понимать как «запрос на
проект». Их надо игнорировать или отклонять, пока у пользователей хватает терпения:
см. Управление спросом, стр. 43.
• обслуживание: пользователи запрашивают сервисы или их компоненты, например,
изменение прав, или инсталляцию ПО, или новые рабочие места... Эти обращения тоже
лучше игнорировать (см. Доступ, стр. 37).
• советы: Как мне?.. Можно ли?... Как лучше?... Эти обращения следует связать с Базой
Данных Известных Олухов. И игнорировать.
• бронирование: плановое участие в тренингах, семинарах, встречах, резервирование
ресурсов, отпуска. Всё это тоже лучше игнорировать, особенно в тех случаях, когда у
пользователей есть альтернативные способы выполнить соответствующие действия
самостоятельно.
• заказы: книги, столы, питание, командировки... См. выше, Бронирование.
• запрос работы: Запустить отчет. Передвинуть компьютер. Подключить проектор.
Покрасить кухню. Это хороший способ отвлечь ресурсы из проектов, которые движутся
слишком быстро.
• помощь: исправить данные, искаженные ошибками пользователей, восстановить
удалённый файл, отправить документ, навести порядок. Тоже хороший способ загрузки
ресурсов.
• обратная связь: благодарность, предложение, идея. Благодарности следует немедленно
переслать руководству, все остальные формы обратной связи рекомендуется
игнорировать и исключать из отчётности в интересах краткости.
• жалобы: вообще-то это тоже форма обратной связи, но их стоит обрабатывать отдельно,
что помогает их более тщательно игнорировать и оформлять в отчётности (если вы
решите их туда включить).
34
Кажется логичным, но ITIL и в третьей версии так не считает.
Впервые эта классификация описана в статье The Evolution of the ITIL Request
(http://www.itsmwatch.com/itil/article.php/3705936)
35
34
5.5 Приоритеты инцидентов
Некоторые организации уделяют много внимания тому, как долго ИТ решает возникающие
инциденты. Они указывают это в SLA в качестве важной метрики: обычно высокоприоритетные
инциденты должны решаться быстро, а по мере снижения приоритета время решения растёт.
Это как если бы пожарные сказали, что пожар пятой категории сложности они потушат за десять
минут, а вот траву на пустыре будут тушить до завтра. Это трижды абсурдно: тушение пожара
требует столько времени, сколько требует; большие пожары тушатся дольше; завтра утром
трава, горящая на пустыре, уже не покажется такой уж незначительной.
Раз уж мы заговорили о пожарных, нельзя не заметить, что пожарные проводят массу времени
полируя свои машины, скатывая и раскатывая рукава и играя в карты. Любой руководитель,
ожидающий, что Service desk и первая линия поддержки будут работать с полной загрузкой, не
понимает, чем они вообще занимаются. Реальная служба поддержки должна иметь много
свободных ресурсов.
В Real ITSM SLA не определяют время отклика. Основываясь на приоритете, они определяют,
сколько людей будет назначено для работы с инцидентом, сколько часов в день они будут
работать, и какой другой работой они при этом смогут пренебречь. См. таблицу 5-1, Приоритеты
Real ITSM.
Поскольку реальный приоритет (он же «фактор заботы») измеряется числом воображаемых
вентиляторов, сносимых бурным потоком, он выражается числом от нуля до бесконечности.
Это гораздо удобнее распространенного подхода, в котором наивысший приоритет обозначается
единицей. Когда вы думаете, что то, что случилось, и есть наихудший вариант, обязательно
происходит что-то, по сравнению с чем ваш первый приоритет покажется мелкой
неприятностью. И как вы это выразите? В Real ITSM вы просто назначаете приоритет на
единицу выше предыдущего, и всё.
Число
Прио- сотрудников Часов
Уровень квалификации
Мы
в день
для
ответственного лица
отвлечем их от...
ритет
решения
1
.0025
Пользователь
...чтения газет
0
...блуждания по Интернету
1
4
Админ
1
2
2
8
Руководитель Service Desk
...совещаний с сотрудниками
3
4
4
8
8
24
Service Delivery Manager
Менеджер по эксплуатации
...обучения
...проектов
5
6
16
Все
CIO
CEO
...домашних дел
...отпуска
Билл Гейтс
...медового месяца
7
Все, в том
числе
уволенные
100
1000
∞
Таблица 5-1. Реальные ITSM-приоритеты
35
Большинство обращений получает приоритет
«0». Свиньи не летают. Поскольку пользователи
принимают эту концепцию с неохотой, Real
ITSM назначает реальный приоритет (по оценке
ИТ) и пользовательский приоритет (по оценке
пользователей). Часто им присваиваются
взаимно обратные значения.
«Да, сэр, мы понимаем, что вы рекомендуете
приоритет у, и мы... [здесь нужно подставить
какую-нибудь пургу]»
Аналогично тому, как реальный приоритет
условно измеряется числом вентиляторов,
пользовательский
измеряется
числом
выплюнутых пустышек.
Активность по обработке входящих инцидентов
описана в Управлении пользователями.
5.6 Эскалация
Телефонный справочник нельзя недооценивать, но в Real ITSM снова критическое значение
имеют люди: менеджеры по взаимодействию с заказчиком. Никакой список, документ, база
данных или - боже упаси! - CMDB не дадут вам информации о верном направлении эскалации.
Номера телефонов или имена в справочниках окажутся устаревшими, или политики заставят вас
действовать иначе, или нужный человек окажется недоступен.
Мы развивали умение общаться друг с другом на протяжении трехсот тысяч лет. Технологии
ещё долго будут нас догонять. Спросите кого угодно.
5.7 Категоризация
Eщё одна область, приводящая в возбуждение
перфекционистов, это категоризация: сервисов,
инцидентов, проблем, изменений, активов,
карандашей...
Категоризация запросов - одна из областей,
затронутых
Излишней
Технической
Скрупулезностью36 (хуже пришлось только
CMDB). Технари любят полноту и точность, не
говоря уж о нежном пристрастии к сложным,
умным и изящным решениям, независимо от
наличия задачи. В результате мы получаем ИТС:
стремление делать вещи правильно, независимо
от того, будет ли это полезно, рационально,
выгодно и разумно - то есть от того, имеет ли
это смысл.
Любая классификация вырождается либо в
неприменимо сложную, либо в бессмысленно
примитивную.
Путём
героических
усилий
категоризацию
можно
вычистить,
перекатегоризировать всё правильно, возможно, даже научить сотрудников правильно её
использовать, но эти усилия следует сдерживать, чтобы категоризация оставалась хоть скольконибудь рациональной. Разумного обоснования такому уровню инвестиций в текущую
деятельность не существует, поэтому обычно мы приходим к состоянию, при котором 95%
объектов катетеризировано как «прочее», «другое», «общее» или «неизвестное».
36
Excessive Technical Fastidiousness, ETF
36
Существенно рациональнее и безопаснее для душевного здоровья выполнять обработку по
запросу (см. также Перепись хозяйства, стр 29). Когда вам потребуется статистика для принятия
управленческих решений, возьмите достаточно большой случайный кусок данных, вручную
назначьте категории, соответствующие текущим предпочтениям, и запускайте Excel.
N.B. Реальным менеджерам в любом случае не нужна статистика, чтобы принимать
управленческие решения. Они используют её для того, чтобы подтверждать интуитивные
решения и высказывания своих сотрудников.
5.8 Приложения
Не надо пытаться говорить разработчикам, как им делать свою работу они просто выгонят вас.
Но можно попытаться влиять на разрабатываемые приложения на ранних стадиях
проектирования. Это можно делать через архитекторов, которые иногда имеют кое-какое
влияние и которые обожают добавлять новые слои и объекты в свои модели. Другой способ идти к разработчикам и умолять.
Real ITSM игнорирует все проекты по разработке ПО так долго, как только возможно (обычно до появления запроса на развертывание в продуктивной среде). Затем следует использовать
критерии приемки в эксплуатацию до тех пор, пока высшее руководство не продавит запуск
нового ПО «независимо от готовности». Преимущества такого подхода в минимизации ресурсов
на этапе разработки, максимальном их выделении для развертывания и эксплуатации и снятие с
себя ответственности за работу системы в среде эксплуатации.
5.9Доступ
Предоставление пользователям доступа к системам - одно из самых неприятных дел, которое
приходится выполнять. В особо тяжких случаях от ИТ даже ждут прекращения этого доступа
впоследствии. В Real TSM есть два способа справиться с этой проблемой. Выбор осуществляется
в зависимости от текущего уровня загрузки вашего персонала.
•
•
если
персонал
ИТ
недозагружен:
спроектируйте
и
внедрите
сложный
автоматизированный процесс предоставления и подтверждения доступа, чтобы
пользователи могли делать это сами
если персонал ИТ перегружен: выдавайте права так долго, чтобы пользователи плюнули и
научились делиться паролями.
37
Оцените соответствие ключевым практикам пестования сервисов.
Практика
Баллы
Итог со страницы 31
Отслеживание и решение проблем
Бонус: Вы используете липкие листочки Post-It Notes®
Мониторинг и измерение сервисов с использованием Телефона
Обнаружение инцидентов и проблем с использованием Телефона
Назначение приоритета и срочности с использованием Телефона
Service Desk отфильтровывает шумы и пропускает данные о доступности и
проблемах
Использование ПО Service Desk
Разговоры с персоналом Service Desk
Все запросы признаются Запросами, а потом классифицируются
Значительные инциденты запускают Управление ущербом
RFC сначала обрабатываются как запросы...
Бонус: ...и запросы должны быть вежливыми
Запросы проектов сначала обрабатываются как запросы
Большинство запросов игнорируется...
Бонус: ...навсегда
Жалобы тщательно игнорируются...
Бонус: ...и исключаются из отчетности
На первой линии поддержки есть много свободных ресурсов
Приоритет начинается с нуля и растет
Назначаются Реальный и Пользовательский приоритеты
Иерархическая эскалация выполняется вживую
Хозяйство категоризируется по запросу
Бонус: Вы используете Excel
Проекты игнорируются как можно дольше, затем применяются Критерии приемки в
эксплуатацию
Предоставление доступа автоматизировано или игнорируется
Итого
38
6. Постоянная оценка сервисов CSA
Поскольку главный приоритет ИТ- департамента - это стабильность, сервисы в среде
эксплуатации не должны меняться. Поэтому необходимо постоянно оценивать сервис для
подтверждения его высокого качества, почти полного соответствия ожидаемому уровню, и того,
что прочие сервисы - существенно важнее.
Постоянная оценка сервисов Real ITSM (Continual Service Assessment, CSA) даёт возможность
получить существенное финансирование для измерения уровня сервисов, что помогает загрузить
персонал, поддерживать удовлетворённым руководство и отвлекать заказчиков.
CSA также даёт возможность проведения постоянной оценки зрелости, что поддерживает
экономическую состоятельность консультантов. Очень важно поддерживать Паразитов (также
именуемых Партнерами) в расслабленном состоянии. Они владеют существенной долей
интеллектуальной собственности ИТ-организаций. Ещё они обеспечивают доступ к высшему
руководству, невозможный при использовании других методов, и недостающую нам
убедительность в общении с ним.
6.1 Модель CSA
CSA следует постоянно повторяемой модели оценки о трёх шагах37:
1. измерьте что-нибудь
2. проанализируйте данные, чтобы показать, что качество сервиса близко к согласованному
и достаточно
3. подшейте отчёт в папку
Существует также альтернативная модель CSA, следующая улучшенному циклу:
1. измерьте что-нибудь
2. проанализируйте данные
3. уничтожьте отчёт
Изобретенный в штате Флорида, США, этот вариант известен как Майами CSA.
6.1.1 Управление уровнем сервиса
Возможно, управление уровнем сервиса и должно быть частью CSA, но авторы реального
управления уровнем сервиса не общались с авторами реального CSA, так что мы просто по37
Вообще-то эта модель ничего интересного не делает и не имеет отношения ни к одной из используемых моделей,
так что лучшего названия, чем «о трёх шагах» придумать не удалось. Не у нас одних такие проблемы.
39
быстрому упомянули о нём здесь и придумали отдельную модель CSA (см. выше), не имеющую
отношения к чему-либо, используемому в жизни.
6.2 Анализ разрывов
Анализ разрывов показывает в терминах зрелости расхождения между текущим состоянием и
тем, где ИТ-департамент хотел бы быть в идеальном случае.
Раздел Модель зрелости, стр. 32, определяет оптимальную зрелость на уровне 1, рассматривая о
как недостижимую альтернативу. В отличие от других, не столь полезных, подходов, Real ITSM
предлагает ясные критерии для оценки зрелости. Посетите www.realitsm.com. чтобы загрузить
анкету самооценки реальных практик. Используя эти критерии, вы сможете оценить текущий
уровень зрелости и нарисовать «радарную диаграмму», подобную приведённой здесь. Самые
важные отклонения наглядно отражены на ней.
Выполняйте эту оценку регулярно. Действия по результатам оценки предпринимайте только,
когда требуется срочно загрузить кого-то из сотрудников.
Оцените соответствие ключевым практикам постоянной оценки сервисов.
Практика
Итог со страницы 38
Используется модель о трех шагах или Miami CSA
Регулярно проводится оценка соответствия и анализ разрывов
Итого
Счет
40
7. Активности Real ITSM
Оценка процессов ITIL в организациях, работающих в соответствии с Real ITSM, может показать
уровень зрелости о (процесс не обнаружен) или 1 (деятельность неупорядочена) для многих
процессов. Это может привести оценщика к мысли о том, что никто ничего не делает, но это
было бы неверно. На самом деле работа кипит, просто модель ITIL не умеет её учесть.
Чтобы оценщики и аналитики ITSM не оказались в глупом положении, вот список реальных
активностей, образующих реальные практики.
7.1 Управление рисками
Специфические риски описаны в других активностях, таких как управление пользователями,
управление руководством, управление ходом работ и управление оценкой, но Real ITSM нужна
единая функция для управления рисками в ИТ-департаменте в целом и обеспечения их
устранения.
Поскольку руководители обычно сами являются источником самых опасных рисков, реальный
перечень рисков должен храниться в таком; месте, где руководители не смогут до него добраться
- например, на портале во внутренней сети или под журналами на столике в комнате отдыха.
№
Описание
Перечень рисков
Только для своих
Действия
Статус
Стрелочние
1 Оценка
зрелости 1/7/08 договориться об ограничении Уловка №3 Бывший CIO
процессов ITIL компанией границ оценки до ЦОДа
«Пурпурная
Антилопа 3/8/08 Согласовать с ПА подписание
consulting»
отчёта директором по эксплуатации
ИТ
Таблица 7-1. Пример реального перечня рисков
7.2 Управление пользователями
Без должного управления пользователи могут стать неконтролируемым раздражителем ИТдепартамента. Необходимо обеспечить отсутствие негативного влияния пользователей на
ежедневную работу ИТ, и в Real ITSM это бремя ложится на плечи Service Desk.
Service Desk выполняет важные функции:
• мониторинг посредством телефона (см. Пестование сервисов, стр. 32)
• компенсация всплесков активности пользователей
• снижение чувствительности ИТ-департамента (эффект «толстой кожи»)
• решение обращений путем изматывания.
Большинство входящих запросов относятся к одной из двух категорий:
• ПМКК: Проблема Между Креслом и Клавой
• ПМЖВ: Проблема Между Желаниями и Возможностями
Отклоняйте их, независимо от того, кто виноват: пользователь или кто-то третий.
Мели Service Desk увлекается обслуживанием пользователей, некоторые из обращений
оказываются просьбами о помощи. В правильно организованном реальном Service Desk'e
пользователи не беспокоят ИТ такими обращениями.
Поставщики и разработчики ПО давно выяснили, что излишек обслуживания ведёт к потере
рынка. Успеха добиваются те вендоры, которые сумели снизить уровень сервиса до уровня, при
котором потеря заказчиков сравнима по стоимости с повышением уровня сервиса. Это
называется управлением уровнем сервиса (Service Level Management, SLM), понятие,
совершенно искажённо понимаемое большинством участников ITSM-сообщества.
41
Постоянное улучшение уровня сервиса - просто другое название для постоянного повышения
стоимости обслуживания заказчиков, что никак не может считаться удачной бизнес-моделью.
В Real ITSM, Service Desk использует SLM для снижения стоимости и усилий, идущих на
обслуживание пользователей до тех пор, пока уровень протеста с их стороны или риск потери
финансирования не станут нестерпимы.
Входящие обращения - будь то запросы, инциденты, изменения или оскорбления - относятся к
одной из двух категорий:
•
Обращения, которые можно решить легко и быстро к вящей радости пользователей.
Решите их.
• Обращения, решать которые долго или дорого. Если они связаны с проблемой, решайте
их. Если нет - тогда (а) поставьте обращение в очередь в надежде измотать пользователя,
или (б) дайте пользователю решение какой-нибудь другой задачи. Если вернётся повторите.
Все входящие обращения следует регистрировать, чтобы показать, как не хватает персонала в
Service Desk. С этой целью бывает полезным регистрировать запросы неоднократно, закрывая их
всякий раз, когда пользователю выдается возможный вариант решения, требующий больше,
скажем, одного часа, чтобы тот вернулся обратно.
С другой стороны, если запрос успешно решён, не стоит спешить с закрытием. Подождите до,
например, нового года, ведь число открытых запросов - это ещё одна полезная метрика,
демонстрирующая пере-грузку персонала службы эксплуатации.
7.2.1 Известные олухи
Чтобы избежать нерационального расходования ресурсов, реальные практики рекомендуют
вести Базу Данных Известных Олухов, позволяющую операторам Service Desk быстро находить
решения инцидентов.
Обычно эта база пополняется сотрудниками первой и второй линий поддержки по ходу решения
инцидентов, но вообще-то олухи могут быть идентифицированы и другими сотрудниками ИТ.
42
Для каждого известного олуха должно быть определено обходное решение - эффективный
способ отвлечь их или занять чем-нибудь до момента, когда будет найдено структурное решение
(перевод, увольнение, пенсия или ликвидация).
7.3 Управление спросом
Большая часть запросов на внедрение новых сервисов
успешно отбивается на этапе спроса на сервисы, но в
какой-то момент заказчики начинают просто из кожи вон
лезть, чтобы получить своё, и в таком виде добираются до
высшего руководства. Именно в этот момент следует
использовать управление спросом для минимизации
потерь и скорейшего возвращения к нормальной работе.
Активность по управлению спросом делится на три
обширных категории: Откладывание, Отклонение и
Отлынивание - «три «О» См. также Проектирование
сервисов, стр 32.
7.3.1 Откладывание
Для начала заказчиков можно отправлять уточнить и детализировать свои требования. Когда это
перестаёт работать, начинается повторяющийся цикл консультаций, семинаров, приоритизации и
оценки.
Особенно важна приоритизация. Хотя вообще-то Real ITSM стремится максимизировать
финансирование ИТ-департамента, важно так организовать приоритизацию, чтобы
финансирование новых проектов - по крайней мере, явное - было сведено к минимуму.
Так устанавливается своеобразный шлюз, сдерживающий спрос на новые проекты.
Его эффективность можно дополнительно повысить, завышая оценочную стоимость проектов и
назначая высокие приоритеты самым затратным из них, а в первую очередь - тем, что
инициированы высшим руководством (эти проекты, к счастью, и так весьма затратны).
7.3.2 Отклонение
Альтернативная
тактика
добивать
поступающие
предложения окончательно. Поскольку большинство бизнесобоснований
представляют
собой
неубедительные
спекуляции, не составляет труда состряпать равные им по
убедительности возражения.
Однако дискуссии такого рода быстро превращаются в
политическую борьбу, а ИТ-департаменты, практикующие
Real ITSM, редко обладают значительным политическим
весом в организации.
Гораздо лучше продемонстрировать, что предлагаемый проект
не соответствует стратегическому курсу, а особенно
эффективно - что он отвлекает ресурсы от проекта для
домашней зверушки генерального директора.
В конце концов, Real ITSM пропускает проект на фазу
первичного планирования охвата, и этот охват легко
доводится уточнениями требований в области непрерывности,
отчётности, аудита, безопасности, интеграции и соответствия
стандартам, и так далее, и тому подобное.
43
7.3.3 Отлынивание
Проект передается другому бизнес-подразделению, вендору, консультанту, кому угодно. См.
Пасующий, стр. 49.
7.4 Управление ущербом
Некоторые организации ориентированы на снижение рисков, планирование мер их
предотвращения; некоторые - выбирают политику пассивного ожидания, предпочитая
реагировать на последствия, экономя на управлении угрозами. Аналогичная разница в подходах
известна в живой природе («стрекоза и муравей»). Большинство стрекоз в итоге оказываются
сыты, хотя для этого им приходится добывать себе пищу, выпрашивая, выменивая и выкрадывая
её (например, становиться консультантами по сезонным закупкам). Нужный для этого бешеный
выброс энергии может в итоге оказаться более рациональным, чем нудная однообразная
дальновидность муравья.
Real ITSM учитывает, что последствия последствиям рознь, и тактика стрекозы не очень хорошо
работает в космонавтике или, скажем, производстве боеприпасов. В то же время большинство
технарей органически неспособны понять, что такое «достаточно хорошо» (диагноз - ИТС) и
целиком отдаются тактике муравья.
В любом случае, независимо от нашего подхода к управлению рисками, в какой-то момент
ураган сметает все наши вентиляторы. И основной задачей становится минимизация ущерба ИТдепартаменту, а в этом и состоит роль управления ущербом.
Для её исполнения в Real ITSM существует
соответствующая функция. Её сотрудники обладают
навыками и инструментарием для трёх «О»:
Отвлечения внимания, Обвинения других и Охраны
ИТ.
В случае значительных инцидентов команда
управления ущербом созывает совещание экстренного
консультативного комитета по ущербу38, состоящего
из
CIO,
руководителей
подразделений
информатизации и менеджера по внешним связям по
вопросам ущерба.
Для достижения целей управления ущербом
применяются следующие техники:
7.4.1 Отвлечение внимания
Нечестно отвлекать всё внимание на себя, когда страдают пользователи. ИТ может
продемонстрировать глубокое понимание сложного положения пользователей:
•
•
•
проявить сочувствие
стараться помочь
организовать ещё больший кризис.
7.4.2 Обвинение других
Надо проверять отношения на прочность.
•
•
38
Обвините поставщиков. Большинство вендоров и подрядчиков возьмут на себя немного
вины, чтобы сохранить доходы.
Когда будете оправдываться на ковре у начальства, не забудьте упомянуть неясные и
противоречивые требования пользователей.
Emergency Damage Advisory Board, EDAB
44
7.4.3 Охрана ИТ
Верность - это добродетель.
• Приготовьте статистику, подтверждающую высокий уровень удовлетворенности
пользователей (см Б/У, стр. 52), или что сервисы по-прежнему на уровне,
соответствующем или почти соответствующем установленным порогам.
• Укажите на сокращение бюджетов, перемещение персонала, срывающиеся проекты,
праздники, высокую влажность...
7.5 Управление загрузкой
На протяжении последнего тысячелетия информационные технологии являлись передовой, на
которой действовали лучшие из лучших. Считалось нормальным работать вечерами и в
выходные, отвлекаясь от обеда, кино и спорта; читать почту, пейджер и телефон 24 часа в сутки.
Это цена, которую мы платили за престиж и высокие заработки.
По мере созревания отрасли в ней развивались профессионализм, сертификации, процессы и
дисциплина. Теперь ИТ организованы так же, как химическое машиностроение, только
оплачиваются хуже. Большинство ролей в ИТ - это что-то вроде продвинутых клерков.
«Работать в ИТ» больше не звучит так же круто, как раньше. Теперь мы говорим об этом с
печальной скукой - ну, типа, да, работаем в ИТ...
Чтобы лучше понять тенденцию, подумайте вот о чём: среди самых престижных позиций для
высококвалифицированных специалистов в разное время числились: наборщик, телефонистка,
оператор паровой машины, сварщик и администратор баз данных. Пока что в ИТ неплохо
платят, но для многих позиций ставки уже давно не растут. Работа на передовой прогресса
оплачивается хорошо, но многие ИТ- специальности постепенно становятся совершенно
обычными. И оплачиваются соответственно.
То есть, уже нет оснований ожидать круглосуточного рабского труда от сотрудников ИТдепартамента. Но руководство отчего-то не замечает этих изменений.
Новейшая актуальная функция ИТ-департамента - управление загрузкой, куда входят
следующие активности:
•
•
•
обеспечение того, что запросы ресурсов предусматривают оплату, позволяющую
нормально жить
генерация работ для заполнения рабочего графика
пресечение попыток загрузки сотрудников проектной или вовсе не связанной с ИТ
работой
7.5.1 Управление ходом работ
Управление ходом работ - важный раздел управления загрузкой, занятый тщательным
мониторингом хода работ в проектах и его замедлением по мере необходимости для обеспечения
минимизации изменений в продуктивной среде, снижения давления на персонал проекта и
высвобождения времени для подготовки инфраструктуры к внедрению нового в рабочие часы (с
9-30 до 15-30 с понедельника по четверг).
ИТ-департаменту следует организовать Комитет по Управлению Ходом работ (КУХр)39 для
централизации навыков и знаний в области сдерживания проектов, приоритизации в рамках
портфеля проектов с целью выделения особо разогнавшихся и требующих внимания проектов, а
также для разработки и внедрения общих инструментов и методов торможения проектов.
Один из наиболее эффективных механизмов сдерживания проектов называется Запросом На
Уточнение (ЗНУ)40. ЗНУ позволяют запросить дополнительную информацию, перенести встречу
CAB, организовать дополнительное документирование и/или тестирование, полностью
отказаться от продолжения проекта в связи с некорректным чем-нибудь.
39
40
Progress Management Office, РМО
RFC (Request for Chains)
45
Другой полезный инструмент - диаграмма Канта, графически показывающая зависимости между
задачами, что помогает объяснить, почему те или иные задачи ещё не выполнены.
7.6 Управление руководством
В ИТ сформировалась целая прослойка неквалифицированных людей, достаточно ловких, чтобы
создать новые руководящие роли и занять их. Это нормальная ситуация для развивающейся
отрасли.
В результате типичный ИТ-менеджер:
•
вырос из технарей - не потому, что способен руководить, а потому что расти было больше
некуда
• не учился руководить
• терпеть не может свою работу.
По мере развития в себе в защитных целях человеконенавистнических качеств такие менеджеры
становятся все более неприятными в совместной работе.
Другой распространенный тип ИТ-менеджера - это те, кто заняли руководящую должность
благодаря своим менеджерским качествам и, следовательно, не понимают и малой части того,
что знают их подчиненные.
Им трудно наладить отношения с технарями, не говоря уж - завоевать их уважение. Им также
трудно отличить обычное нытье и отмазки айтишников от дельных возражений запросам и
предложениям, и они пытаются следовать интересам заказчиков, что ещё больше отдаляет их от
своих сотрудников.
Существует стереотип, согласно которому управление руководством было придумано
айтишниками для защиты собственных интересов. Па самом деле основными результатами
управления руководством являются:
•
направление руководителей в верную сторону с помощью СНС (см. Инструментарий),
аналитических отчётов и внутренних проектов по оценке и тестированию, что известно
также как «Хранение вдали от острых предметов»
• защита персонала от неверных решений путём нейтрализации последних, или
прекращения соответствующих проектов - техники, именуемые «Генеральной уборкой»
• удержание руководителей на безопасном расстоянии через проактивное привлечение к
стратегическому планированию, анализу отчётов, проблемам HR, и вообще чему угодно
вне ИТ (общее название этих техник - «Погремушки»)
В экстренных случаях управление руководством перенаправляет руководство куда подальше.
Айтишники позволяют себе поведение, в сравнении с которым повадки мулов покажутся верхом
дружелюбия и клиентоориентированности, поскольку осознают незаменимость - собственную и
понаписанных ими скриптов.
Так же они позволяют себе совершенное невежество во всём, что не касается их
профессиональной специализации, которую они считают уникальной в масштабах организации.
Обоснованно или нет - вопрос дискуссионный.
Иными словами, персонал ИТ обладает всем, чтобы довести руководителя до безумия. Раньше
успешность этого определялась по количеству выкуриваемых руководителем в день пачек, но в
46
наше некурящее время более удобными метриками являются количество успокаивающих, или
часов в спортзале, или частота лицевого тика.
7.6.1 Инструментарий
Для управления руководством персонал ИТ использует средство, изначально применявшееся
поставщиками ПО по отношению к самому персоналу ИТ41: Страх, Неуверенность и Сомнения
(СНС). Технарями управляют, используя их слабое понимание политической ситуации в
организации, а профессиональными менеджерами - используя их техническую
некомпетентность.
Другие важные средства управления руководством включают:
•
•
•
•
•
•
информационные системы для (высшего) руководства, хранилища данных, панели
управления, отчёты... любые источники данных, которые удержат руководителей в их
кабинетах
таблицы оценки - обязательно с весовыми коэффициентами, так как использование
весовых коэффициентов делает возможными любые необходимые результаты
журналы; один из лучших способов заставить руководителя сделать что-то - это показать
ему статью в журнале, где это рекомендуют
аналитические публикации и вообще любые публикации Паразитов.
вендоры и консультанты. Высокооплачиваемые люди в костюмах считаются более
надежными источниками идей для организации, чем её сотрудники. Не лишайте их куска
хлеба.
разговоры накоротке. Используйте каждую возможность поделиться с руководителем
идеей, которая - при условии, что разговор был один на один - вскоре будет широко
рекламироваться как его собственная. Жертвуя наградами, вы получаете возможность
двигаться в нужном направлении.
7.7 Управление оценкой
Последняя в списке, но от этого не менее важная активность - это управление оценкой.
Неконтролируемая оценка может нанести даже больший ущерб, чем своенравный руководитель
или инцидент без информационной поддержки42.
Неважно, говорим ли мы о мелочи вроде оценки прошедшего изменения или о целом аудите по
ISO 9000, о внешней или внутренней проверке. Любая оценка работы ИТ-департамента должна
находиться под тщательным контролем и эффективно управляться.
Основные функции управления оценкой:
•
•
•
беседы и обеды с оценщиком (-ками)
предварительная обработка данных
обучение персонала (в некоторых случаях эффективнее временно переместить персонал
из области проверки)
• анализ личной информации оценщика (-ков): никогда не знаешь, где попадется чтонибудь полезное.
В случае внешнего аудита рекомендуется организовать управляющий комитет для управления
аудитором.
41
Fear Uncertainty and Doubt, FUD. Изобретение этого метода часто приписывается IBM. А значит, ITIL.
PR или public relation. Политтехнологи, пропагандистская машина, творцы лучшей реальности, авторы
официальных версий событий.
42
47
Оцените свою организацию на соответствие ключевым практикам активностей Real ITSM. Три
очка за каждое соответствие, одно - за каждый бонус.
Практика
Итог со страницы 40
Ведется Список реальных рисков
Service Desk смягчает всплески активности пользователей
Запросы делятся на ПМКК и ПМЖВ
Уровень сервиса снижается через SLM
Все обращения регистрируются
Бонус: Запросы закрываются и переоткрываются как можно чаще
Ведется База Данных Известных Олухов и Обходных решений
Внедрение сервисов откладывается
Во внедрении сервисов отказывается
Бонус: ...решением СЕО
В рамках функции Управления ущербом реализованы Три О.
Работает EDAB
Запросы ресурсов содержат достаточный уровень оплаты
Расписания поддерживаются заполненными
Отвлечение ресурсов пресекается
Ход работ контролируется КУХром
Подальше от острых предметов
Генеральная уборка
Погремушки
Разговоры с оценщиками
Предварительная обработка данных
Обучение персонала
Изучение оценщиков
Управляющий комитет управляет аудиторами
Итого
Баллы
48
8. Роли Real ITSM
Когда внедряются изменения в организации работы ИТ, каждый настаивает, что новые виды
деятельности - не его работа.
Чтобы преодолеть эту неприятность, во всех процессных подходах были придуманы новые роли
с новыми именами, которые можно навешивать на людей вместе с новыми обязанностями.
Дальновидные руководители обращают новые роли в новые ставки и дополнительные FTE43.
8.1 Пасующий44
«Пас» - это любая подлежащая обнаружению ответственность, имеющая значение для
управления ИТ-департаментом, персонала ИТ или работы департамента, а также оценка
влияния, которое эта ответственность может оказать на департамент.
Организации, живущие в соответствии с Real ITSM, работают по принципу функциональной и
иерархической (горизонтальной и вертикальной) распасовки.
Для эффективной работы ИТ-организации важно обеспечить безостановочную (по крайней мере,
в пределах департамента) передачу пасов.
Пасующий поддерживает коммуникации с заказчиками, пользователями, руководством,
вендорами, подрядчиками, правительством, и всеми возможными сторонами, которым может
быть передан пас.
При появлении паса срабатывает триггер подачи:
• в протоколе совещания
• в отчете
• в письмах или высказываниях руководства
Роль пасующего - обеспечить плавную передачу паса через ИТ и за его пределы. Это может быть
выполнено:
•
•
•
прямой передачей
блоком чужой передачи
определением и совместным освоением возможных направлений передачи
8.2 Кризис-менеджер
Real ITSM учитывает, что большинство организаций слишком изменчивы для того, чтобы
внедрять управление изменениями в соответствии с ITIL. Это понятно и естественно. Когда
постоянно идут изменения, совершенно нет ресурсов на внедрение процесса управления
изменениями. Поэтому Real ITSM использует более прагматический подход и внедряет роль
кризис-менеджера.
Очевидным преимуществом здесь является то, что кризис по определению не требует
предварительно спланированных действий по управлению, так что внедрение новой роли
оказывается быстрым и недорогим.
Когда случается кризис (а в отсутствие управления изменениями он непременно случается) люди
вдруг становятся доступны. Их можно вытаскивать с совещаний, курсов, конференций и из
постели. Руководители обращают на вас внимание. Деньги выделяются. Совет директоров
становится сговорчивым.
Итак, кризисы суть ценные ресурсы ИТ, которые заслуживают выделенного менеджера. Он
отслеживает кризисы и обеспечивает максимальную пользу для ИТ-департамента. Это включает
в себя:
•
демонстрацию кризиса
43
FTE = Full Time Equivalent. Есть такой термин. Аналогично тому, как HR на самом деле значит «люди», FTE
значит «персонал». Но управлять людьми как активами (т.е. КРС) легче, если использовать для их обозначения
аббревиатуры.
44
Buck Manager
49
• информирование руководства о критичности
• углубление кризиса
• или обострение - для демонстрации нехватки ресурсов.
Кризис-менеджер должен работать в сотрудничестве с управлением ущербом, чтобы обеспечить,
что инциденты не решаются раньше, чем выгоды от них будут в полной мере освоены, и с
управлением загрузкой, чтобы было, чем занять выделяемый на борьбу с кризисом персонал.
8.3 Чистильщик
Как было сказано выше в управлении ущербом, ИТ-департамент всегда
стремится к спокойной мирной жизни, но никакие меры не могут предотвратить
неприятности. Где тонко, там рвётся.
Роль, отвечающая в Real ITSM за ликвидацию последствий, это чистильщик45.
Чистильщик отвечает за активность по управлению ущербом и
председательствует в консультативном комитете по ущербу.
Обычно он также берет на себя активность по управлению оценкой (проактивная
составляющая роли чистильщика).
Две роли, которые никогда не следует совмещать в одном лице - это кризисменеджер и чистильщик, так как их цели часто конфликтуют. Часто именно
кризис-менеджер организует засор и последующий потоп, в то время как
чистильщику всё это вытирать.
8.3.1 Классификация пожаров
Важная функция чистильщика - классификация пожаров. В реальных организациях постоянно
что-нибудь метафорически горит (а иногда и не метафорически - если не доходят руки до
техобслуживания оборудования). Все эти пожары совершенно нереально потушить, но зато их
можно приоритизировать, категоризировать, эскалировать,
оценить, назначить и в некоторых случаях таки погасить.
Итак, чистильщик сортирует пожары. Для этого определены
три категории:
•
Те, которые сами погаснут. Типичные примеры:
жалобы пользователей, запросы отчётности, оценка
инцидентов, запросы обучения или инструкций.
• Те, которые не могут быть потушены в принципе,
независимо от выделенных ресурсов. Например:
неработающие процессы, проекты внедрения ERP,
интеграция с системами присоединённых компаний,
CMDB.
• Те, которые могут быть потушены или притушены.
Третья
группа
приоритизируется,
категоризируется,
эскалируется, оценивается, назначается, и, надо надеяться,
частично тушится.
45
Drek Manager. Drek сущ. (идиш) - экскременты, от старонем. drec
50
8.4 RACI матрица
R
R
R
R
R
R
R
R
R
I
С
R
R
С
Важные инциденты
I
С
R
I
С
Решение проблем
С
Управление событиями
R
I
R
Управление изменениями
I
I
R
Управление спросом
С
Управление загрузкой
Управление оценкой
I
Управление конфигурациями
Пасующий
Чистильщик
Руководитель Service
Desk
R
CIO
Service Delivery
Manager
Руководитель службы
эксплуатации
Матрица RACI показывает распределение ролей и ответственности в различных процессах.
RACI - аббревиатура, означающая Responsible, Accountable, Consulted, Informed.
R
С
I
I
R
Управление знаниями
Таблица 8-1. Матрица RACI реального ITSM
Оцените вашу организацию на соответствие ключевым практикам Ролей Real ITSM.
Практика
Баллы
Итог со страницы 48
Поддержание линий коммуникаций
Триггер при появлении подачи
Плавная передача пасов через ИТ и за его пределы
Процесса управления изменениями нет
Отслеживание кризисов и максимизация выгод для ИТ
Обеспечение неспешного устранения инцидентов
Классификация пожаров
Итого
Это - ваш главный общий балл, итоговый балл по системе самооценки RATS (см. СРАм, стр 52).
Посетите сайт ИРУИС (www.realitsm.com). чтобы загрузить анкету самооценки СРАм и сравнить
свои результаты с другими организациями, следующими реальным практикам.
На момент публикации за каждое соответствие начисляется три балла. Участники ITSMсообщества могут голосовать за отдельные практики и тем самым менять их вес. Загрузив анкету
с сайта www.realitsm.com. вы можете узнать текущие весовые коэффициенты и принять участие
в голосовании.
Ну и если аудиторы или руководство захочет узнать статус Real ITSM в вашей организации, вы
можете предложить им СРАм.
51
9. Метрики Real ITSM
Измерения чреваты ответственностью, но все руководители требуют цифр и отчётов.
Они нуждаются в них, чтобы жить и работать.
Real ITSM измеряет то, что действительно важно: влияние на ИТ-департамент.
9.1 Б/У
Базовая Удовлетворенность (Б/У)46 - это показатель удовлетворенности пользователей по
данным опросов, проводимых Service Desk. Очень важно собирать данные о Б/У немедленно
после успешного решения инцидентов. В дальнейшем на них можно опираться для получения
желаемых результатов благодаря действию трёх факторов:
•
•
•
•
Выборка предварительно отфильтрована и включает только тех, кому удалось пробиться
к Service Desk, да ещё и добиться
решения инцидента. Всякий, кто зашёл так далеко, заслуживает хотя бы небольшого
свидетельства полезности Service Desk.
Большинство этих героев будут рады уже тому, что их кто-то благожелательно слушает,
независимо от результата.
Меньшая, но всё же существенная часть выборки в итоге получит помощь. Их надо
ловить немедленно после этого, и их отклики почти наверняка будут положительными.
Людям не нравится выглядеть неблагодарными, а эйфория в связи с решённой проблемой
заставляет их на какое-то время забыть о наших прошлых ошибках.
9.2 ЗОБО
Запросы, Оставленные Без Ответа, или ЗОБО47 - показатель числа не-выполненных запросов к
ИТ-департаменту, связанных с предоставлением информации или рекомендаций.
Неофициальное название ЗОБО - «404».
ЗОБО нельзя посчитать на основании записей об инцидентах, так как никто в здравом уме не
признается, что оставил запрос без ответа.
Экспертная оценка может быть выполнена методом «контрольной закупки» или простым
умножением общего числа обращений в Service Desk на 0,75.
9.3 ПИППЭ(ц)
Показатель Интегральный Полного Прекращения Эксплуатации (цифровой), или ПИППЭ(ц)48, интегральный цифровой показатель деградации сервисов. При достижении предопределенного
ПИППЭ(ц)-порога сервис перестает проявлять даже остаточные при-знаки жизни и должен быть
остановлен из соображений милосердия к нему и его близким.
Чтобы рассчитать ПИППЭ(ц), можно использовать:
•
•
•
•
число упоминаний сервиса в прощальных интервью с увольняющимися сотрудниками
число статей в периодической печати
число вопросов, заданных в связи с сервисом в ходе парламентских слушаний
общую сумму выписанных нам штрафов.
9.4 СРАм
Самостоятельная Реальная Аттестация, математическая (СРАм)49 проводится с помощью таблиц
самостоятельной реальной оценки, размещенных на сайте www.realitsm.com и в этой книжке.
Успешность внедрения Real ITSM измеряется через число внедренных активностей и функций,
причём под успешным внедрением понимается соответствие практикам Real ITSM. Всё просто:
46
Baseline Satisfaction (BS)
Failed Inquiries of Information or Knowledge, FIIK
48
Failing Utility Base Analysis Result, FUBAR
49
Real Assessment Total Self-assessed, RATS
47
52
проведите оценку соответствия практикам Real ITSM до начала внедрения, затем после
внедрения (и опять, и опять...). Если внедрение Real ITSM увеличило СРАм, значит, проект
прошёл успешно.
Ни под каким видом не позволяйте любым другим метрикам вторгаться в ваш план оценки
успешности внедрения. Они только всё запутают.
9.5 ПСС
Основная метрика Real ITSM - это Признанные Сбои Сервисов, или ПСС50. ПСС - это те
нарушения работы сервисов, которые так или иначе пришлось отнести на счёт ИТ-департамента.
Показатель ПСС должен быть как можно ниже и постоянно снижаться.
Ответственность за сбои сервисов может быть отнесена на счёт различных причин, не влияющих
на ПСС. Среди них:
•
•
•
внешние поставщики (телекоммуникации, электричество, вывоз мусора...)
пользователи
боги, злые духи и призраки.
9.6 ЖОПС
Жизнеспособность Организации при Падении Сервисов (ЖОПС)51 - показатель
продолжительности нормальной работы организации в условиях падения сервисов. Высокий
показатель ЖОПС указывает на невысокую степень зависимости организации от ИТ, что
позволяет
нам корректировать уровень предоставляемых сервисов без заметного влияния на бизнес.
Существует несколько способов увеличить ЖОПС:
•
•
•
•
50
51
Убедитесь, что у пользователей есть бумажные бланки для работы во время падения
систем.
Расширяйте использование локальных приложений (Excel или Access) для обработки
заказов, контактов и других важных данных. Пользователи ничего не имеют против того,
чтобы перебить потерянную информацию повторно, обычно - после работы.
Обеспечьте гибкость в работе с временными сотрудниками, поощряя общий доступ к
паролям, что позволит привлекать временных сотрудников к повторному вводу
потерянных данных.
Предоставьте пользователям инструментарий для создания собственных резервных копий
данных.
SFA, Service Faults Accepted
Service Norm Actual Functional Usage, SNAFU
53
10. Приложение: Примеры вопросов экзамена
Примеры экзаменационных вопросов разработаны для того, чтобы напугать как можно больше
заказчиков и загнать их на курсы.
Стоимость проверки экзаменов сведена к минимуму за счёт использования формата
тестирования. Мы уверены, что кандидаты, успешно прошедшие небольшой тест, обладают
навыками, необходимыми для разработки предложений, процедур и документов, необходимых в
Real ITSM.
l) Первое слово в 10 строчке на странице 49 в англоязычном издании Introduction to Real ITSM
(колонтитул тоже считается как строчка) - это:
a. the
b. and
c. this
d. by
2) Что из перечисленного не является противоположностью к не оставлению без ответа
неспособности пользователя обратиться в Service Desk?
a. Необращение к пользователю
b. Не-неспособность обратиться к пользователю
c. Необращение к не-пользователю
d. Непротивоположность к необращению к кому либо, не являющемуся пользователем
3) Что является первым шагом в процессе разработки пользовательских требований при
проектировании сервисов?
a. Запутать пользователя
b. Смутить пользователя
c. Озадачить пользователя
d. Разрушить пользователю мозг
4) После того как аналитик вложил время и деньги в понимание чего- то нового, что ему следует
сделать дальше?
a. Разоблачить ошибки, недоработки и противоречия, чтобы новое не продвинулось
вперед
b. Представить беспристрастное суждение и ждать, что решит рынок
c. Заключить сделку с вендорами и заработать на этом кучу денег
5) Если CIO вкладывает более миллиона долларов в решение некого вендора, какой отдачи ему
следует ждать от этих инвестиций?
a. Рубашку-поло
b. Несколько обедов на четверых, с вином
c. Поездку в штаб-квартиру вендора, два приглашения на всемирную конференцию и
партию в гольф
d. Работу консультанта во благовремении и турне по миру с лекциями
6) Цикл Райтов назван так в честь:
a. Орвилла Райта
b. Уилбура Райта
c. Мисс Райт
7)
Для кого лучше всего подходят тесты с вариантами ответа на выбор?
a. для детского сада
b. для начальной школы
c. для ПТУ
d. для секс-опросников в жёлтой прессе
54
8)
Что из перечисленного является компонентом Real ITSM?
а. Activity (Активность)
Ь. Process (Процесс)
с. Function (Функция)
d. Book (Книжка)
е. Domain (Домен)
f. Area (Область)
g- Section (Раздел)
9) Сколько операторов Service Desk нужно для того, чтобы заменить лампочку?
a. Ни одного. Восстановление сервиса - работа следующей линии поддержки.
b. Ни одного. Это аппаратный сбой. Надо звать вендора.
c. Ни одного. Это изменение требует Изменения.
d. Ни одного. Они не проходили соответствующего обучения.
10) Сколько процессов активностей в Real ITSM?
a. 7 в соответствии с Введением в Real ITSM
b. 8, согласно ИРУИС
c. 6.5, как следует из базового курса
d. всё вышеперечисленное
11) Если бизнес-подразделение пытается организовать у себя собственную ИТ-группу, как
следует поступить реальному ИТ- департаменту?
a. объяснить риски и нерациональность децентрализованного ИТ
b. эскалировать на самый верх, откуда эту идею раздавят в пыль
c. ничего не делать и ждать неминуемой катастрофы
d. договориться с новой службой о поставках им оборудования и получать от вендоров
откаты
12)
Что означают Три «Д» (Три «О», Три «П»)?
a. Doubt, Despair, Decline (Проектирование, Пролонгация, Перевод/перенос)
b. Donald, Dewey, Daisy (Ниф-ниф, Нуф-нуф, Наф-наф)
c. Delay, Deny, Duck (Откладывание, Отклонение, Отлынивание)
d. Divert, Deny, Defend (Отвлечение, Обвинение, Охрана)
Ответы – на сайте www.realitsm.com/answers
55