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

С фактами не спорят.
Их объясняют.

Василий Гроссман

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

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

Говорим на одном языке

Что такое ИТ-услуга

Книги библиотеки ITIL®, начиная с версии 3 (май 2007 года) содержат великолепное определение:
Услуга — способ предоставления ценности заказчикам через содействие им в получении конечных результатов, которых заказчики хотят достичь без владения специфическими затратами и рисками1.Данное определение ставит два важных акцента, которые потребуются нам в дальнейших рассуждениях:

  • Нематериальность услуги (это свойство отличает услугу от товара). В определении выше этот акцент зафиксирован словами «содействие … в получении конечных результатов … без владения специфическими затратами и рисками». Это соответствует и отечественной нормативной базе. Так налоговый кодекс РФ (статья 38 п.5) дает следующее определение: «Услугой … признается деятельность, результаты которой не имеют материального выражения, реализуются и потребляются в процессе осуществления этой деятельности».
  • Назначение услуги — предоставлять ценность заказчикам. Это, в частности, значит, что поставщик услуг должен представлять не только то, что он умеет делать, а то, почему и насколько это ценно для его заказчиков. Это, в свою очередь, значит, что нужно учиться говорить с заказчиком на одном языке. Разумеется, для бизнес-руководителей эта идея совсем не нова. Уже много лет существуют методики, направленные на систематическое выявление потребностей заказчиков и проектирование своих продуктов и услуг в максимальном соответствии с ними (например, Quality Function Deployment). Однако для внутренних поставщиков ИТ-услуг этот акцент во многом инновационен, поскольку расходится с традиционными представлениями об организации ИТ-подразделений по функциональному принципу (мы еще будем говорить об этом).

Но дальше определения услуги дело начинает откровенно буксовать. Ведь ИТ-руководителям важно определить не только, что такое услуга вообще, а что такое ИТ-услуга (их область ответственности). Здесь ITIL неожиданно предлагает следующую пару определений:

ИТ-услуга — услуга, предоставляемая поставщиком ИТ-услуг.
Поставщик ИТ-услуг — поставщик услуг, предоставляющий ИТ-услуги внутренним или внешним заказчикам.

Масло масляное.

Любопытно, что стандарт ISO/IEC 20000–1:2011 «Information technology — Service management» изящно избегает вопроса об определении ИТ-услуги тем, что просто не использует этот термин! Вместо этого используется понятие «услуга», а согласно названию стандарта речь, очевидно, идет об услугах, которые касаются информационных технологий.

Вместе с тем для того, чтобы дать корректное определение ИТ-услуги, достаточно сформулировать, чем ИТ-услуги отличаются от прочих, то есть какую ценность для заказчика и каким образом они обеспечивают. Для этого открываем книгу «ITIL Service Strategy 2011 Edition» (ISBN 978-0113313044) и в разделе «2.1.6 Utility and warranty» читаем:

  • чтобы услуги создавали ценность, они должны приносить пользу (utility) и обладать определенными гарантиями предоставления (warranty);
  • польза от ИТ-услуги заключается ИЛИ в устранении ограничений (например, раньше мы не могли предоставлять клиентам банка дистанционное банковское обслуживание, а теперь можем), ИЛИ в повышении производительности труда (например, раньше формирование отчета занимало неделю, а теперь — 10 минут);
  • в отличие от товаров, услуги не обладают внутренней ценностью. Ценность услуги определяется потребителем на основании того, какие новые возможности он получает, используя данную услугу.

Таким образом, определение ИТ-услуги может быть представлено в виде:

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

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

Вот некоторые примеры ИТ-услуг:

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

Что такое сервисный подход

Как показали бурные дискуссии ITSM-сообщества в 2012 году, это понятие также требует некоторого пояснения. Не буду вдаваться в детали, отмечу лишь наиболее важные моменты.

В книге «ITIL Service Strategy» 2007 года было несколько упоминаний понятия сервисный подход (service-oriented approach). Суть сводилась к тому, что сервисный подход есть концепция, перенесенная в ИТ из традиционного бизнеса. Она заключается в том, что ИТ-организации меняют фокусирование в диалоге с заказчиками — ставят во главу угла не области собственной компетенции (сети, приложения, базы данных), а ценность для заказчика, которую все эти компетенции, будучи правильно организованы, могут обеспечить. Именно так выживают и развиваются компании, оказывающие услуги на коммерческой основе, то есть бизнес (внутренним ИТ-поставщикам это свойственно в гораздо меньшей степени).

Аналогичного мнения придерживаются и международные эксперты, которым мы задавали вопрос о том, существует ли понятие «сервисный подход» и если да, то что оно означает. Их ответы приведены во врезке.

Да. Сервисный подход это средство для ИТ-подразделения предоставлять ценность в форме услуг

Стюарт Ранс (Stuart Rance), Hewlett-Packard, консультант по стратегическому управлению услугами. Автор книги ITIL Service Transition 2011 года. ITIL Expert.

Да. Это когда ИТ-подразделение думает о потребностях заказчика, когда оно является клиенто-ориентированным

Дэйв Джонс (Dave Jones), Pink Elephant EMEA Ltd., ведущий консультант. ITIL Expert.

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

Маартен Бордвейк (Maarten Bordewijk), Ensink & van Gool, старший тренер, консультант, коуч. Рецензент книги ITIL Service Transition 2007 года. ITIL Expert.

Да. Для меня … это значит, что ваши мысли и действия преодолели уровень «систем» и вы теперь осознаете важность фокусирования на «услуге», потребляемой пользователем

Дэвид Ретклифф (David Ratcliffe), Pink Elephant, CEO.

Следовательно, учитывая приведенные выше определения услуги и ИТ-услуги, понятие сервисного подхода в применении к ИТ можно определить следующим образом:

Сервисный подход в области ИТ — способ организации взаимодействия с ИТ-подразделением как с поставщиком ИТ-услуг.

А поскольку сервисный подход означает фокусирование ИТ-подразделения на ценности для заказчика, а ценность, как мы говорили выше, может быть получена заказчиком только при наличии и пользы (utility), и некоторых гарантий (warranty), сервисный подход требует баланса между ориентацией на новые потребности заказчиков и соблюдением взятых на себя обязательств (см. Рисунок 1). Необходимость поиска такого баланса вытекает из простого факта — ресурсы любой организации ограничены. Поэтому хвататься за реализацию каждой новой идеи заказчика нельзя, но и не слышать заказчика, не осознавать его потребностей — неприемлемо (а для коммерческой компании — смертельно).

picture slm part1 picture1

Рисунок 1. Баланс сервисных отношений

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

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

Любопытную (как всегда) позицию занимает IT-Skeptic (Роб Ингланд). Вот, что он пишет в одной из своих заметок3:

Есть люди, которые думают, что ITSM — это изобретение подобно бензиновому двигателю или обручу для гимнастики, что ITSM будет впоследствии заменен чем-то еще. Это не так. ITSM – это открытие. Оно объясняет нам природу окружающей реальности, как физика.

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

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

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

За (преимущества)…

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

Более четкое определение взаимных обязательств

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

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

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

Выравнивание видения поставщика и потребителей

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

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

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

Основа для объективной оценки деятельности ИТ-подразделения

Проектная деятельность измеряется относительно легко. В самом деле, есть список проектов, есть сроки и ответственные. Все, что нужно — это ввести менеджерам проектов (и их руководителям) KPI по своевременности и качеству выполнения проектов. Качество может, например, оцениваться опросом заинтересованных сторон по утвержденной форме, рассчитываться как доля реализованных проектных требований или определяться проектным комитетом при закрытии проекта на основании заданных критериев. Допустим K1 — это доля своевременно выполненных проектов (в диапазоне от 0 до 1), а K2 — оценка качества (также от 0 до 1). Тогда KPI = K1 x K2. Устанавливаем целевое значение (например, 0.9) и в целом задача решена.

Но деятельность по сопровождению и эксплуатации информационных систем измерить и оценить существенно сложнее. Что значит «Все работает, как надо»? Что значит «Достаточно быстро»? Что значит «С приемлемым уровнем доступности» (и что такое доступность вообще)? Универсальных ответов на перечисленные вопросы нет.

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

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

Своевременное планирование и обоснование ресурсов

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

Однако после окончания проекта жизнь не застывает в статичной форме. Сегодня приложение использует тысяча пользователей, а через год за счет подключения филиалов пользователей станет в три раза больше. Сегодня система обслуживает 100 000 транзакций в день, а завтра в связи с планами по захвату рынка их ожидается в десять раз больше. Сегодня отчет формируется по базе в 100 Гбайт, а в следующий год размер базы может составить 0,5 Тбайт. И перечисленные изменения не обязательно случатся в форме проекта. Правда заключается в том, что они происходят постоянно, постепенно, не всегда предсказуемо и очень редко — управляемо (по крайней мере, с точки зрения поставщика ИТ-услуг).

Появляется ли при этом потребность в дополнительных ресурсах? Конечно. Но в отличие от проекта связать их с потребностями конкретных бизнес-подразделений гораздо труднее. Получается, что ИТ-подразделение постоянно просит ресурсы для себя, хотя на самом деле это в корне неверно.

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

Экономически обоснованное управление ИТ

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

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

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

Бочка меда

Таким образом, организация сервисных отношений даже с внутренним поставщиком ИТ-услуг (без явно выраженных коммерческих отношений) может обеспечить:

  • более четкое определение взаимных обязательств;
  • выравнивание видения поставщика и потребителей;
  • основу для объективной оценки деятельности ИТ-подразделения;
  • своевременное планирование и обоснование ресурсов;
  • экономически обоснованное управление ИТ.

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

… и против (трудности)

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

Отсутствие конкуренции

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

Широкое распространение модели декларативного управления

Зачем ИТ-руководителю искать возможности для оптимизации, если сверху в любой момент может быть спущено требование «сократить затраты на 30%»? Чтобы выжить в такой ситуации необходимо не оптимизироваться, а напротив — сохранять избыток ресурсов, которыми в крайнем случае можно пожертвовать (чтобы, пережив, снова накапливать внутренний резерв).

Отсутствие спроса на управление уровнем ИТ-услуг со стороны бизнес-подразделений

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

Сложности с формированием бизнес-ориентированного каталога ИТ-услуг

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

Сложности с закреплением сквозной ответственности за ИТ-услугу

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

Нехватка навыков ведения переговоров и позитивной установки у ИТ-менеджеров

Присутствуя на встречах по согласованию SLA между ИТ-поставщиком и заказчиком ИТ-услуг, я много раз слышал от менеджеров ИТ-услуг ответ: «Нет, мы это сделать не можем, потому что…». И действительно, не все пожелания заказчика можно реализовать. Но если хотя бы в половине случаев ответ менялся на «Хорошо, мы можем это сделать, но для этого нам понадобится…», прийти к компромиссу было бы гораздо проще.

Заключение

Перечисленные трудности приводят к тому, что проекты по организации управления уровнем ИТ-услуг становятся настоящим вызовом ИТ-руководителю. Они требуют от него видения, воли и авторитета для последовательного проведения комплексных организационных изменений на протяжении нескольких лет, возможно с серьезным пересмотром оргструктуры ИТ-подразделения, принципов оценки и стимулирования персонала (еще одна область, где свобода ИТ-руководителя может серьезно ограничиваться корпоративными стандартами), наконец своей собственной роли в организации.

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

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

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


Сноски

  1. Здесь и далее определения из книг ITIL® представлены в редакции официального русскоязычного перевода словаря терминов ITIL®, выполненного itSMF России (http://itsmforum.ru/ZAM-test/Russian_2011_Glossary_v2.0.pdf).
  2. Под информационными процессами здесь мы понимаем процессы, связанные со сбором, обработкой, хранением, передачей или распространением информации.
  3. http://www.itskeptic.org/content/2012-7-itsm-discovery-not-invention-and-itil-documents-it
  4. О формировании бизнес-ориентированного каталога ИТ-услуг мы будем подробнее говорить в следующей статье.