Звоните: +7 (495) 517-57-25

В конце 2013 года мы выпустили русский перевод весьма интересной книги про каталог ИТ-услуг: «Каталог услуг для успешного управления ИТ». С одним из авторов, Троем Дюмуленом (Troy DuMoulin), мы и решили побеседовать, чтобы задать вопросы, которые у нас остались после её прочтения. Беседу вёл Дмитрий Исайченко.

troydumoulin Вице-президент компании Pink Elephant. Certified IT Service Manager and ITIL® Expert. Является признанным экспертом в области управленческого консалтинга ИТ. Имеет обширный опыт проектной деятельности в области ITSM с локальными и международными компаниями.

Дмитрий: Давайте начнем с того, что определим, о какой бизнес-среде мы говорим. Расскажите, пожалуйста, SLM и SLA в США и Канаде — обычные «вещи», так делают все или это все же больше практика немногочисленных лидеров? Вопрос в первую очередь про ИТ-подразделения в составе не-ИТ-компаний, не про коммерческие ИТ-компании, потому что с ними, конечно, все гораздо более понятно.

Трой: Отвечу так: SLA действительно являются частью общих практик. Большинство ИТ-организаций имеют ту или иную форму явных или неявных соглашений о результатах своей работы. Главная сложность состоит в том, что в качестве основы этих SLA используются технологические домены, а не услуги и даже не ИТ-системы. Такие соглашения касаются скорее отдельных ИТ-компонент или их групп — например, SLA на приложение, изолированное от инфраструктуры, или на группу серверов.

Разумеется, ни один из приведенных примеров не представляет собой услугу, которая действительно потребляется бизнес-пользователями. Кроме того, в большинстве случаев нет или недостаточно возможностей по измерению фактических показателей в сравнении с согласованными, а также нет OLA или других соглашений, которые бы объединяли различные группы в пределах ИТ-организации общим видением того, в чем заключаются результаты работы и насколько они хороши.

Можно утверждать, что фактически нет практики управления уровнем ИТ-услуг (SLM) — фокус исключительно на создание SLA. Подробнее об этом я размышляю в своей заметке «Как провалить SLM с помощью SLA».

Дмитрий: В Вашей книге Вы даете читателям весьма дельный совет: начинать думать о сервисном каталоге не в терминах ИТ-систем и компонент, а с точки зрения бизнес-процессов. Насколько привычно и естественно для компаний в Северной Америке говорить на языке бизнес-процессов? Много ли компаний, с которыми Вы работали, имели актуальный каталог бизнес-процессов?

ИТ-организации думать в терминах бизнес-процессов абсолютно не привыкли, и это самая суть проблемы.

Трой: ИТ-организации думать в терминах бизнес-процессов абсолютно не привыкли, и это самая суть проблемы. Ценность, которую приносят информационные технологии, необходимо осознавать и формулировать с точки зрения бизнес-пользователей. Идентификация технических услуг, таких как хостинг, хранение данных или сеть вполне может быть выполнена снизу вверх. Но бизнес-услуги необходимо определять, двигаясь сверху вниз.

Это очень серьезный скачок в восприятии для большинства ИТ-специалистов, поскольку они, к сожалению, имеют весьма слабое представление о бизнес-процессах. Именно понимание бизнес-процессов — первая тема нашего учебного курса, посвященного каталогу услуг. Я озвучивал это в одном из недавних вебинаров: «Анатомия сервиса — Что предшествует формированию каталога услуг».

Дмитрий: Если компания, с которой Вы работаете, не имеет актуального представления о своих бизнес-процессах, как Вы справляетесь с этой ситуацией?

Трой: В этом случае вы берете организационную структуру компании и приступаете к анализу. Большинство организаций структурированы по своим основным бизнес-процессам, направленным на создание ценности для клиентов. Есть подразделения, отвечающие за работу с рынком, есть поддерживающие функции, такие как HR, финансы, маркетинг и так далее.

В книге этому посвящена иллюстрация 2.1 на странице 42.

Дмитрий: Практика построения каталогов услуг на основании бизнес-процессов довольно быстро привела нас к идее типовых отраслевых каталогов (для банков, ритейла, страхования и так далее). Такие каталоги могут быть сформированы на основании отраслевых процессных моделей, вроде eTOM или PCF и могут служить хорошей отправной точкой для тех компаний, которым не хватает собственного видения. Что Вы думаете об этой идее? Есть ли аналогичные «типовые» каталоги у Pink Elephant?

Трой: Абсолютно согласен, это отличные ресурсы. Кто-то однажды сказал мне, что редактировать всегда проще, чем разрабатывать с нуля. И eTOM, и PCF предоставляют общую информацию о процессах, с которой можно начинать, или, по крайней мере, дают возможность сопоставить стандартные отраслевые процессы с процессами своей организации. При этом очень важно, чтобы идентифицируемые таким образом процессы назывались привычным для данной конкретной организации образом, поскольку необходимо, чтобы «бизнес узнавал себя», открывая каталог услуг.

Дмитрий: По итогам ряда наших проектов мы обнаружили, что каталог услуг, сформированный на основании бизнес-процессов компании, сложнее в использовании при классификации обращений пользователей на первой линии поддержки. Как вы преодолеваете эту сложность?

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

Дмитрий: Одной из наиболее распространенных проблем, на наш взгляд, является отсутствие или нехватка средств мониторинга и измерения бизнес-процессов и, таким образом, поддерживающих их ИТ-услуг. До начала проекта многие ИТ-специалисты утверждают, что они умеют измерять что угодно, но как только мы начинаем говорить о сквозных характеристиках услуг, значимых для потребителя, уверенность ИТ-специалистов начинает быстро таять. Исходя из Вашего ответа на первый вопрос, Вы также встречаетесь с этой проблемой?

Трой: В целом, да. Вообще, в ITIL говорится о трех типах метрик: технических, процессных, сервисных. Для бизнес-подразделений, использующих каталог услуг, значимым является лишь ограниченный набор метрик:

  1. Доступность (время предоставления сквозной услуги, а не отдельных приложений).
  2. Надежность (количество инцидентов за период в разбивке по тем или иным классификаторам).
  3. Качество выполнения сервисных запросов (в какой степени соблюдаются согласованные характеристики выполнения сервисных запросов).
  4. Качество управления портфелем услуг (критерии качества проектов в привязке к ИТ-услугам, доля сервисных проектов, выполненных в срок и в бюджет с учетом полученных результатов).
  5. Характеристики функциональности услуг (например, доля платежных чеков или экзаменов студентов, обработанных к установленному сроку).

Все перечисленные метрики опираются на развитые средства сбора данных, формирования, анализа и представления полезных отчетов. Например, без ясного понимания взаимосвязей ИТ-систем, зафиксированного в CMDB / CMS, весьма сложно измерять доступность услуг.

Дмитрий: Изучение книг ITIL и общедоступных материалов по ITSM может создать у читателя впечатление, что каталог услуг всегда должен содержать поддерживающие услуги с соответствующими OLA. Однако практика показывает, что появление сервисных отношений и OLA в пределах ИТ-подразделения иногда ведет к трудностям в управлении, поскольку приводит к более высокой степени автономности ИТ-групп. Ситуация становится похожей на взаимодействие с внешними поставщиками, но отличается отсутствием таких эффективных рычагов влияния, как прибыль и конкуренция. Поэтому мы считаем, что идею OLA следует использовать осторожно, после тщательной оценки руководителя, ответственного за конечный результат — качественные ИТ-услуги. Что Вы думаете об этом?

Трой: Я убежден, что каталог услуг, прежде всего, является средством коммуникации, если угодно — обучения, и используется для решения очень разных задач. Когда вы предоставляете потребителю информацию об услуге, важно относиться к этому как к возможности показать ему зависимости данной услуги от других услуг, как внутренних, так и внешних. Например, дистанционное банковское обслуживание или услуги ATM зависят от хостинга, хранения данных, сети, поддержки, обеспечения безопасности и так далее.

Я убежден, что каталог услуг, прежде всего, является средством коммуникации.

Если ваш каталог выполнен в виде web-приложения, я бы предложил представить поддерживающие сервисы html-ссылками, чтобы помочь пользователю лучше понять эти зависимости.

Далее, я считаю, что для того, чтобы сформировать SLA с заказчиком, вам действительно сначала необходимо иметь внутренние соглашения. Более того, вы вполне можете разнести разработку и заключение OLA и SLA по времени. И вы можете разработать и опубликовать каталог услуг задолго до того, как будете готовы к заключению SLA. Эта концепция постепенно нашла свое отражение в ITIL — в более поздних его версиях Service level management (SLM), Business relationships management (BRM) и каталог услуг (как продукт процесса управления каталогом услуг) отделились друг от друга, и это важное изменение мы с коллегами обсуждаем в подкасте «Радио для практиков. Выпуск 41: Эволюция и потомки SLM».

Так что до того, как вы можете перейти к заключению SLA, владелец соответствующей бизнес-услуги должен разработать OLA с владельцами поддерживающих сервисов.

Дмитрий: В Вашей книге Вы приводите несколько примеров экономического обоснования проектов по реализации SLM. Эти примеры основаны на том, что основное осязаемое и измеримое преимущество, которое заказчик получает от SLM, это экономия средств за счет стандартизации используемых и предоставляемых потребителям технологий. Однако очень схожие примеры легко отыскать практически в любой публикации по ITAM — выясни, что ты используешь, определи, что тебе действительно нужно, избавься от остального, включая соответствующие платежи, и получи свои 150% ROI. И весьма вероятно, что это может быть сделано и без организации SLM. Поэтому следующий вопрос — как вы обосновываете SLM-проекты на практике и какие аргументы работают лучше всего?

Трой: Этот вопрос — отличная возможность еще раз показать, что проект по разработке каталога услуг — это не то же самое, что проект по организации SLM или BRM. SLM нацелен на создание системы метрик, связанных с услугами, которые выравнивают внутренние и внешние соглашения, чтобы обеспечить соблюдение требований потребителей услуг, а также на организацию отчетности, которая используется владельцами услуг в рамках программы совершенствования услуг (CSI) и процессом BRM для вовлечения потребителей. SLM направлен не на сокращение затрат, а на измерение полученных потребителями услуг результатов.

С другой стороны, проект по формированию каталога услуг имеет несколько целей.

Прежде всего, необходимо четко разделить каталог услуг и те технические средства, которые мы используем для публикации каталога, для того, чтобы проинформировать бизнес, какие услуги ему доступны. Мои комментарии выше относятся к принципам идентификации услуг, а не к используемым технологиям (это совсем не одно и то же, хотя мы часто перепрыгиваем с одного на другое).

На самом деле я считаю, что до тех пор, пока вы не планируете сделать ваш каталог услуг действенным инструментом, который помогает в выполнении запросов и мониторинге / измерении услуг, вам лучше потратить свои деньги на красивую глянцевую маркетинговую брошюру, чем на web-каталог, на который никто не зайдет больше одного раза.

Первый шаг — добиться понимания сервисов в вашем портфеле, который включает в себя разрабатываемые, предоставляемые и архивные услуги. От того, как вы решите публиковать и использовать вашу структуру услуг, зависит очень многое:

  1. Возможности стратегического вовлечения заказчиков
  2. Возможности использовать те или иные модели расчета стоимости услуг
  3. Возможности учитывать при проектировании функциональные и нефункциональные атрибуты услуг
  4. Возможности по измерению услуг и заключению соглашений
  5. Возможности по предъявлению требований к внешним услугам
  6. Возможности по определению элементов релизов, которые необходимо тестировать только вместе
  7. Возможность определить, затрагивает ли изменение те или иные атрибуты услуги или нет для выбора оптимального уровня утверждения
  8. Возможность определения зависимостей между услугами и компонентами для вашей CMS
  9. Возможность понимания стандартных сервисных запросов для каждой услуги и порядка их выполнения
  10. Возможность классификации базы знаний по назначению, использованию и бизнес-ценности
  11. Возможности по классификации объектов обработки для оперативных процессов (управление инцидентами, проблемами, запросами пользователей и так далее).

Создание и запуск web-ориентированного каталога услуг не должно восприниматься как цель проекта по разработке каталога услуг. Это просто один из возможных шагов, который нужно принять во внимание.

Дмитрий: Эффективное управление услугами предполагает ясное осознание ограничений. Когда вы платите за потребляемые услуги, ваши деньги могут являться мерой того, что для вас посильно и достаточно. Однако при организации сервисных отношений с внутренними ИТ-подразделениями довольно часто бывает так, что SLA заключается с одним субъектом (например, с HR-департаментом), а согласование бюджета выполняют совсем другие субъекты (например, бюджетный комитет или совет директоров). Это дополнительно усложняет сервисные отношения и приводит к тому, что заказчики склонны требовать «все и сразу». Вы считаете, что каждый SLM-проект должен создавать ту или иную систему возмещения затрат — в виде прямых денежных отношений или в той или иной форме компенсации на уровне управленческого учета? Вы действительно внедряете такие практики в каждом своем SLM-проекте?

Трой: В тот день, когда организация приступит к идентификации услуг и публикации каталога, она должна ясно осознавать, что вопрос «А сколько это стоит?» не за горами. Проект по созданию каталога услуг создает основу для расчета стоимости услуг, однако сама система взаиморасчетов должна создаваться позже, отдельным проектом. Для одного проекта вполне достаточно такой сложной задачи, как формирование каталога услуг.

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

Строго говоря, выражение «определение ИТ-услуг» вообще не очень корректно. На самом деле вы просто выявляете и документируете услуги, которые вы уже предоставляете. Это позволит вам знать состав портфеля своих услуг, лучше корректировать и приспосабливать его под потребности заказчика. Чтобы организация могла перейти от управления технологиями к управлению бизнес-ценностью в контексте бизнес-стратегии и портфеля услуг, вам абсолютно необходимо точно знать, что вы делаете и что нужно, чтобы это было сделано.

В тот день, когда организация приступит к идентификации услуг и публикации каталога, она должна ясно осознавать, что вопрос «А сколько это стоит?» не за горами.

Так что можно сказать, что каталог услуг у вас есть прямо сейчас, даже если он пока не опубликован. Однако, пока истина не задокументирована, она относительна и не защищена от субъективных споров без общего согласия о том, что можно улучшить в вашем текущем состоянии. Аналогично вы получаете оплату за ваши услуги прямо сейчас, даже если вы не кладете на стол ваших заказчиков оформленный счет. Запрос на предоставление ежегодного бюджета — тоже форма взаиморасчетов, ведь вы просите дать вам денег за те результаты, которые обеспечиваете. Единственная разница — уровень прозрачности и согласия, которого вы можете достичь сейчас и с которым сможете выжить в будущем, не имея платежеспособного заказчика, который понимает, за что он платит и умеет контролировать получаемый результат.

Закон бережливого производства: первый шаг к улучшению — стабилизация.

  • То, что не определено, не поддается контролю
  • То, что не контролируется, не может эффективно измеряться
  • То, что не измеряется, не может системно совершенствоваться

Более подробную информацию по сервисно-стоимостному анализу вы можете найти в моем подкасте «Радио для практиков. Выпуск 45: Сервисно-стоимостной анализ».

Дмитрий: В Вашей книге Вы уделяете много внимания такому понятию, как сервисное предложение (service offering). Я отлично понимаю, насколько это важно для коммерческих поставщиков ИТ-услуг. Однако для внутренних ИТ-подразделений определение состава услуг чаще всего выполняется для фиксации уже сложившихся отношений между поставщиком и потребителями. То есть, как Вы и говорите, речь идет не о создании новых услуг, востребованных рынком, а об идентификации существующих (хоть и не формализованных) услуг. В такой ситуации сам акт заказа услуг вообще может быть не характерен для сервисных отношений. Почему Вы считаете, что сервисные предложения так важны даже для внутрикорпоративных поставщиков услуг?

Трой: Как я и говорил в ответе на вопрос 8, одной из причин для идентификации и описания услуг является поддержка для процессов управления каталогом услуг и стратегического вовлечения заказчика, что становится возможным в том числе благодаря практике измерения качества услуг.

Однако, другая причина для определения услуг и публикации каталога заключается в том, что все услуги по своей природе основаны на получаемых заказчиком результатах. Что я получаю и как я могу заказать больше? С этой точки зрения нельзя забывать о том, что все услуги имеют один или несколько заказываемых элементов, которые могут быть связаны с разным уровнем предоставления услуги. Например, стандартный ПК, ноутбук, высокопроизводительная станция для инженерных расчетов (три предложения, три заказываемых элемента для услуги «Рабочее место»).

Если вы опубликовали каталог услуг, вам необходимо предоставить пользователям механизм для заказа и получения услуги. Это можно сделать, позвонив в Service Desk или воспользовавшись локальным хранилищем разрешенных приложений, которые могут автоматически устанавливаться по утвержденному запросу с использованием тех или иных механизмов оркестрации.

Дмитрий: Скажите, пожалуйста, какие тенденции в отношении ITSM в целом и SLM в частности Вы видите? Как коммодитизация ИТ и облачные технологии влияют на будущее ITSM как практики управления услугами?

Трой: Облачные технологии требуют высокой степени автоматизации процессов, связанных с каталогом услуг, выполнением запросов пользователей, управлением уровнем услуг, управлением конфигурациями и так далее. Облачные вычисления не создают препятствий ITSM, а напротив — предоставляют бизнес-кейс для более точного определения и автоматизации процессов управления услугами.

Подробнее я обсуждаю этот вопрос в своей заметке «ITSM расцветает в облаках» и на вебинаре «Что сегодня ITSM-лидерам необходимо знать про облака».

  • 1
  • 2
  • 3
  • 4
  • 5
Prev Next

Интервью с Каймаром Кару об ITIL Practitioner

Интервью с Каймаром Кару об ITIL Practitioner

В 2014 году нам уже довелось пообщаться Каймаром Кару, руководителем ITSM-направления в компании AXELOS, когда он был гостем 5-ой ежегодной конференции itSMF России. Тогда разговор шел о лучших в мире ИТ-услугах, настоящем и будущем ITIL, современных тенденциях ITSM. Новым поводом для беседы стал выход «ITIL Practitioner Guidance» — наиболее значительного…

Интервью с Каймаром Кару и Патриком Болджером о будущем ITIL, лучших в мире ИТ-услугах и…

Интервью с Каймаром Кару и Патриком Болджером о будущем ITIL, лучших в мире ИТ-услугах и пользе от ИТ-евангелистов

На 5 ежегодной конференции itSMF России, прошедшей в Москве в сентябре 2014 года, было много иностранных гостей. Одним из ключевых спикеров стал Каймар Кару, руководитель ITSM-направления в компании AXELOS, практически — «главный по ITIL» в современном ITSM-мире. А в секции Cleverics, посвященной взаимодействию ИТ и бизнеса, выступил Патрик Болджер –…

Интервью с Питером Хепвортом о планах развития ITIL, луковой модели и деловых играх

Интервью с Питером Хепвортом о планах развития ITIL, луковой модели и деловых играх

Роман Журавлёв первым из российских экспертов лично побеседовал с исполнительным директором AXELOS Питером Хепвортом. Компания AXELOS с 1 января 2014 года управляет британским «Портфелем лучших практик» (Best Management Practice portfolio), в который входит, например библиотека ITIL®. Роман обсудил с Питером и глобальные, и наши, российские, вопросы обучения, сертификации, продвижения и…

Интервью с Троем Дюмуленом о каталоге услуг и SLM

Интервью с Троем Дюмуленом о каталоге услуг и SLM

В конце 2013 года мы выпустили русский перевод весьма интересной книги про каталог ИТ-услуг: «Каталог услуг для успешного управления ИТ». С одним из авторов, Троем Дюмуленом (Troy DuMoulin), мы и решили побеседовать, чтобы задать вопросы, которые у нас остались после её прочтения. Беседу вёл Дмитрий Исайченко. Вице-президент компании Pink Elephant. Certified…

Интервью с Брайаном Джонсоном о пользе от itSMF

Интервью с Брайаном Джонсоном о пользе от itSMF

В сентябре 2013 года Брайан Джонсон (Brian Johnson) принял участие в IV Всероссийской Конференции itSMF России «Сервисное многоборье. ITSM: от фитнеса– к спорту высоких достижений!» В своём интервью Олегу Скрыннику и Рушану Умерову Брайан рассказал о создании международного ITSM-форума, его ценности и роли в жизни ITSM-сообщества. Брайан Джонсон (Brian Johnson) –…

Интервью с Джоном Стюартом об истории ITIL: как всё было на самом деле

Интервью с Джоном Стюартом об истории ITIL: как всё было на самом деле

Интервью с Джоном Стюартом при участии Брайана Джонсона провели Степан Хрулёв и Олег Скрынник, Cleverics, ноябрь 2013. Джон Стюарт Джон Стюарт учился в университете Глазго и Йоркском университете, окончив которые получил степень доктора наук по квантовой физике. После небольшой академической карьеры, продолжавшейся около пяти лет, он довольно продолжительный период своей жизни –…

Интервью с Александром Левинсоном о сорсинге, ITIL и географии

Интервью с Александром Левинсоном о сорсинге, ITIL и географии

Есть ли жизнь за пределами библиотеки ITIL®? Безусловно! Роман Журавлёв побеседовал с ведущим международным ITSM-экспертом, Александром Левинсоном. Александр Левинсон является одним из пионеров в области управления ИТ-услугами в России. Он, а также Мартен Бордвайк (Maarten Bordewijk) и Ханс ван ден Бент (Hans van den Bent) провели первые сертификационные курсы, положившие начало профессиональному…

Интервью с Яном ван Боном – о менеджменте, книгах и проблемах ИТ-экспертов

Интервью с Яном ван Боном – о менеджменте, книгах и проблемах ИТ-экспертов

В начале июня Москву посетил Ян ван Бон (Jan van Bon) — признанный эксперт в управлении ИТ, основатель портала ITSMPORTAL.com, автор и издатель множества книг по управлению ИТ. Ян – заметная фигура в мировом ITSM-сообществе, и у него есть свое — и часто особое — мнение о том, как развивается…

Интервью с Дэвидом Рэтклифом об организации больших ITSM-конференций

Интервью с Дэвидом Рэтклифом об организации больших ITSM-конференций

В то время как в России практика регулярных больших ITSM-конференций только начинается, за океаном уже накоплен колоссальный опыт проведения интересных тематических мероприятий. Олег Скрынник побеседовал с Дэвидом Рэтклифом, президентом компании Pink Elephant, о том, что необходимо для организации успешного обмена опытом в промышленных масштабах. Дэвид Рэтклиф (David Ratcliffe) — соучредитель и…

Интервью с Аале Роосом об отучении от ITIL, про Service Desk 2.0 и об искусстве…

Интервью с Аале Роосом об отучении от ITIL, про Service Desk 2.0 и об искусстве простых вопросов

В марте 2012 года Роман Журавлев встретился в Хельсинки с Аале Роосом, активным участником международного ITSM-сообщества, колумнистом ITSMPortal.com, консультантом с более чем двадцатилетним опытом. Давно знакомые в сети, Роман и Аале Роос впервые встретились лично. Аале поделился своим взглядом на перспективы ITSM, Service Desk 2.0 и особенности опросов пользователей, а…

Интервью с Дэвидом Кэнноном об ITIL 2011

Интервью с Дэвидом Кэнноном об ITIL 2011

В начале сентября 2011 года Россию посетил Дэвид Кэннон, председатель международной организации itSMF International, активный участник мирового ITSM-движения. Дэвид уже много лет работает в области управления ИТ-услугами, в частности, он принимал непосредственное участие в разработке библиотеки ITIL® (IT Infrastructure Library) третьей версии, а также в её обновлении до редакции ITIL…

Интервью с Маартеном Бордевайком об ITIL, ITSM и ИТ

Интервью с Маартеном Бордевайком об ITIL, ITSM и ИТ

Летом 2010 года Москву в очередной раз посетил Маартен Бордевайк, известный ITSM-тренер, ставший одним из первых западных экспертов в области управления ИТ-услугами, работавших в России. Мы встретились с Маартеном, чтобы побеседовать об ITSM-обучении, профессиональной сертификации, перспективах ITSM в мире и зрелости российских компаний. Маартен Бордевайк (Maarten Bordewijk) проходил обучение в колледже…

Интервью с Дэвидом Кэнноном о проекте ITIL v3 Update

Интервью с Дэвидом Кэнноном о проекте ITIL v3 Update

Одна из важных и горячо обсуждаемых тем в настоящее время — проект обновления третьей версии библиотеки ITIL®, так называемый ITIL v3 Update. Официальной информации о нём крайне мало, и появляется она нерегулярно. Чтобы восполнить вакуум, мы связались с Дэвидом Кэнноном (David Cannon), одним из ключевых участников этого проекта, и взяли…

Интервью с Яном Схилтом о новых методах обучения и будущем ITSM

Интервью с Яном Схилтом о новых методах обучения и будущем ITSM

18 и 19 мая 2010 года Москву посетил известный ITSM-эксперт Ян Схилт, основатель и совладелец компании GamingWorks. Во время своего визита он дал эксклюзивное интервью компании Cleverics, в котором ответил на ряд важных вопросов о назначении и принципах деловых (симуляционных) игр, своём видении будущего ITSM-обучения, а также дал оценку современного…