Tla что это такое itil

Обновлено: 09.05.2024

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

ITIL В широком смысле инцидент определяется как незапланированный инцидент, который прерывает обслуживание или может прервать обслуживание, если не устранить немедленно. Со структурированным ITIL Управление инцидентами Такой подход позволяет предприятиям обеспечить минимальное или почти нулевое влияние на бизнес даже в случае непредвиденных инцидентов.

Что такое SLA?

Соглашение об уровне обслуживания (SLA) - это соглашение или контракт между поставщиком услуг и его клиентом о предоставлении услуг, которые соответствуют ожиданиям клиента.

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

SLA устанавливают объем услуг, запрашиваемых клиентом у поставщика, они определяют метрики, по которым оцениваются услуги, и штрафы в случае невыполнения согласованного уровня обслуживания.

Соглашения об уровне обслуживания технологических компаний могут включать в себя обязательство по обеспечению бесперебойной работы сети на уровне 99.99%. Если этого не добиться, заказчик имеет право сократить свой платеж на определенный процент в зависимости от масштаба отключения. Если вы хотите узнать больше о том, как устанавливать, измерять и составлять отчеты об уровне обслуживания, посетите наш блог на 5 Практические советы по настройке, измерению и составлению отчетов об SLA.

Определение первого ответа на обнаружение инцидента

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

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

Самый важный компонент в управлении инцидентами - служба поддержки

В цикл управления инцидентами вовлечено множество функций. Наиболее важным из них является Service Desk. Без службы поддержки между пользователями и ИТ-командой последняя будет загнана в угол, чтобы заниматься каждой проблемой по мере ее регистрации. При такой неструктурированной практике ИТ-команда может неправильно распределять ресурсы для решения второстепенных проблем и упускать из виду более важные.

Управление инцидентами ITIL

Основные этапы процесса управления инцидентами:

Фильтрация инцидентов и запросов: Каждый запрос пользователя тщательно изучается Службой поддержки и помечается как Инцидент или Запрос. И Инцидент, и Запросы должны иметь конкретные планы разрешения, с большим импульсом для Инцидентов.

Билетная инженерия: После того как запрос был отфильтрован как проблема, Служба поддержки должна зарегистрировать запрос в корпоративной системе с важной информацией, такой как информация профиля пользователя, описание инцидента и вспомогательные данные.

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

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

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

Структурированный подход к процессу управления инцидентами

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

Определение ролей в процессе управления инцидентами

Это основные роли в процессе управления инцидентами:

Объем и процесс управления инцидентами

Чтобы работать над дальнейшими процессами разрешения инцидентов, очень важно определить масштаб инцидентов. Любой случай, который приводит к прерыванию обслуживания, можно назвать инцидентом. Это может включать в себя более системные и серьезные сбои или другие неожиданные проблемы, такие как сбои питания, программные ошибки или повреждение оборудования. Определение масштабов инцидентов обеспечивает эффективное распределение ресурсов, поскольку каждое небольшое прерывание не следует идентифицировать как инцидент.

Четко определенный объем инцидентов приводит к общей схеме управления инцидентами ITIL:

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

Почему необходимо управление инцидентами ITIL?

ITIL Incident Management фокусируется на эффективном восстановлении системы с профилактическими мерами, принимаемыми для устранения повторяющихся проблем. Это обеспечивает минимальный ущерб для операций бизнеса или его отсутствие и помогает поддерживать непрерывность бизнес-процессов в соответствии с уровнями производительности, определенными в SLA. Цель состоит в том, чтобы немедленно восстановить систему до предварительно определенного нормального рабочего режима, проверенного по взаимным договоренностям.

Управление инцидентами: быстрые примеры из практики

Наиболее часто наблюдаемые инциденты попадают в следующие категории:

  1. Ошибка приложения
    1. Все неопределенные ошибки идентифицируются как ошибки приложения и назначаются заранее определенной группе реагирования.
    2. Повреждения данных часто являются отправной точкой для системных сбоев и нарушения бизнес-операций. Для обеспечения его целостности принимаются специальные меры.
    3. Даже самые незначительные ошибки в программном пакете или онлайн-платформе могут отпугнуть пользователей. Следовательно, инциденты не идентифицируются на основе их масштаба и их коллективного воздействия на бизнес-операции пользователей и масштабы.
    1. Аппаратные отказы
      1. Серверы - это центральные системы для размещения и предоставления доступа к цифровым активам как внутренним, так и внешним клиентам предприятия. Если серверные инциденты не будут немедленно устранены, они потенциально могут повлиять на все корпоративные процессы.
      2. Инциденты с сетевым подключением часто нарушают общение по электронной почте и видеочатам, что может напрямую влиять на критически важные бизнес-процессы и повседневные операции.
      3. Простои корпоративных систем напрямую влияют на показатели человеческого капитала. При наличии адекватных резервных копий системы фирма может продолжать повседневные операции даже после запуска процессов разрешения инцидентов.

      В заключение

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

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

      Суть ITSM

      Роль ITSM — служить мостом между разработкой и пользователем, который может быть как нетехническим сотрудником организации, так и клиентом.

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

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

      ITSM фокусируется на этих аспектах и приносит лучшее понимание того, что нужно бизнесу и почему, то есть выступает фундаментом для повторяемых и масштабируемых процессов, сокращает дистанцию между конечными пользователями и IT-отделом. Благодаря этому у клиентов формируются реалистичные ожидания, а задержки между обнаружением проблем и их устранением минимизируются.

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

      Итак, как определить взаимосвязь между ITIL и ITSM?

      Это симбиотические отношения между ITSM и ITIL. ITIL рассказывает, как эффективно работать с ITSM, используя все лучшие практики. Принимая во внимание, что ITSM заботится о том, что доставить и как это сделать.

      Знакомство с методологией ITIL в ITSM

      Менеджмент в IT знает несколько подходов. Главное различие между ними — приоритеты. Один метод сконцентрирован на технологиях (IT Systems Management), другой — на услугах (IT Service Management). Последний обозначается аббревиатурой ITSM и часто встречается в сопровождении другого понятия: библиотека инфраструктуры информационных технологий, или ITIL. В этой части серии статей об ITIL мы рассмотрим роль лучших практик в ITSM, а также совершим экскурс в историю зарождения ITIL и проведем краткий обзор методологии.

      Заключение

      ITIL является синонимом ITSM из-за его популярности, отсюда и путаница. Как вы уже узнали, эти два термина разные, но они дополняют друг друга. ITSM - это «Что», а ITIL - «Как» предоставлять ИТ-услуги.

      Если вы ищете инструмент ITSM, совместимый с ITIL, то не смотрите дальше. Motadata ITSM - это простой, мощный инструмент, который будет перегружать вашу службу поддержки. Попробуйте наш инструмент на 30 дней.

      ITIL и ITSM - насколько они разные?

      Давайте начнем с понимания того, что такое ITIL и ITSM, и их различия.

      Есть и другие фреймворки, такие как ITIL

      Существует множество фреймворков, таких как ITIL, например:

      • Структура бизнес-процессов (eTOM)
      • Цели управления информационными и смежными технологиями (COBIT)
      • DevOps
      • FitSM
      • ISO / IEC
      • Сервис, ориентированный на знания
      • Наклонитесь
      • Microsoft Operations Framework (MOF)
      • Интеграция и управление услугами (SIAM)
      • Интеграция сервисов с несколькими источниками (MSI)
      • Шесть сигм

      Важность SLA

      SLA для конечный пользователь «s спокойствие духа. У них будет an SLA, чтобы они могли см. это всякий раз, когда они требовать в держать их подотчетность поставщика. It также перечисляет детали о том, какой тип обслуживание, которое они получат. In дома их потребности не удовлетворяются, они может смягчить некоторые из ударов by спрашивающий для Денежная компенсация из поставщик услуг. Для многих организаций это форма гарантии, в которой они нуждаются начать прочные отношения с новинка партнер с кем у них нет работавший до .

      Что такое OLA?

      Соглашение об уровне эксплуатации (OLA) - это обязательство или соглашение, которое поставщик услуг устанавливает для своих внутренних клиентов в отношении соблюдения SLA. Чтобы обеспечить бесперебойную доставку услуг, необходимо согласованно использовать как SLA, так и OLA. Гарантия, содержащаяся в SLA, должна быть материальной и полностью поддерживаться OLA.

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

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

      В чем разница между SLA и OLA?

      SLA против OLA

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

      Ключевые различия между SLA и OLA заключаются в следующем:

      1. SLA - это, по сути, соглашения между поставщиком услуг и заказчиком. OLA - это контракты между отделами внутренней поддержки организации, предоставившей SLA.

      2. SLA сосредоточены на сервисном аспекте соглашения, таком как время безотказной работы и производительность услуг. OLA, напротив, представляют собой обязательства по поддержанию службы.

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

      4. Соглашения об уровне эксплуатации носят более технический характер, чем соглашения об уровне обслуживания.

      5. SLA связывает поставщиков услуг с клиентами, в отличие от OLA, поэтому SLA имеют большую целевую группу, чем OLA.

      Давайте попробуем понять эти два термина в другом контексте.

      Если вы хотите построить дом, соглашение между вами и генеральным подрядчиком будет представлять собой Соглашение об уровне обслуживания о том, что и когда нужно делать. Контракт, который генеральный подрядчик составляет со всеми своими рабочими и рабочими, будет соглашением об уровне эксплуатации.

      Заключение

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

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

      В чем разница между SLA и OLA?

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

      Раньше этим легко управлять.

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

      Мы вас не виним! Достаточно сильно усложнить процесс согласования SLA с вашими клиентами. Следовательно, понимание разницы между двумя типами соглашений чрезвычайно важно. Но сначала давайте посмотрим, что означает каждый тип соглашения, а затем углубимся в то, что отличает их.

      ITIL как основа ITSM

      Как уже было отмечено выше, ITIL содержит руководящие принципы по реализации ITSM. Библиотека инфраструктуры IT имеет довольно интересное происхождение: её история тесно связана с британской короной. ITIL был разработан в конце 1980-х Центральным компьютерным и телекоммуникационным агентством (CCTA) Великобритании. Причиной заказа полноценного комплекса лучших практик IT стало низкое качество IT-услуг, оказываемых британскому правительству.

      Таким образом, ITIL был призван улучшить сервис и одновременно с этим снизить затраты на обслуживание. Сейчас ITIL является торговой маркой AXELOS, совместного предприятия правительственной канцелярии Великобритании и лондонской компании Capita.


      / фото Witizia CC

      Как рассказывает пользователям Quora Аманда Фэйрбразер (Amanda Fairbrother), эксперт по ITIL, власти заказали исследование, чтобы определить используемые передовые методы в 2,5 тыс. различных организаций — крупных и малых, государственных и частных, занятых во всех отраслях промышленности. Итогом работы стал свод руководящих принципов Government Information Technology Infrastructure Management, который и лег в основу первой версии ITIL. Она была опубликована в 1989 году и имела сорок томов. Годом позже библиотека начала распространяться по миру за пределы Великобритании.

      В 2001 году мир увидел ITIL v2, где фокус сместился на процессную составляющую (с технических аспектов), а количество томов сократилось до семи. Этому предшествовало использование основ ITIL компанией Microsoft в 2000 году для создания собственной методологической модели Microsoft Operational Framework (MOF).

      В 2007 году была выпущена ITIL v3. Количество томов опять сократилось (до пяти), а акцент был сделан на жизненном цикле IT-услуги: стратегия, проектирование, преобразование, эксплуатация, непрерывное улучшение услуг. Основной посыл ITIL v3 в актуальной редакции заключался в ложности подхода «процесс ради процесса».

      Коммерческий потенциал ITIL получил массовую оценку в начале 90-х вместе с тем, как ряд частных организаций и британский Колледж Государственной Службы получили статус обучающих платформ методологии ITIL. Тогда же аттестационная комиссия ISEB, входящая в состав Британского компьютерного общества (BCS), приобщилась к первым тестам на сертификат ITIL.

      Постепенно организации из всех отраслей промышленности как частных, так и государственных, начали осознавать преимущества ITIL. Этому поспособствовал запуск Великобританией и Нидерландами в первой половине 1990-х ассоциации IT Service Management Forum с целью распространения методологии в Европе. По состоянию на 2016 год она насчитывает 6 тыс. участников по всему миру.

      На этом этапе ряд компаний, таких как HP, IBM, Procter & Gamble и DHL, начали вкладывать значительные средства в ITIL. Что касается США, то туда ITIL «добрался» сравнительно поздно. Однако в своем исследовании доктор экономических наук Маурицио Марроне (Mauricio Marrone) утверждает, что по состоянию на 2009 год 45% респондентов из 364 американских компаний использовали ITIL, а 15% планировали это делать.

      ITSM VS ITIL - разница между ITIL и ITSM

      Путаница оправдана, потому что эти два термина кажутся одинаковыми, но на самом деле они разные.

      В этом блоге вы узнаете об ITSM и ITIL; Насколько они разные, и их отношения.

      ITIL сегодня

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

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

      Проектирование услуг является этапом жизненного цикла нового или модифицированного сервиса, который разработан и подготовлен к фазе преобразования. Основной задачей здесь выступает разработка окончательного решения для удовлетворения потребностей бизнеса. Как говорит Элисон Картлидж (Alison Cartlidge) из IT Service Management Forum, проектирование услуг должно быть целостным процессом и учитывать четыре фактора: людей (навыки и компетенции, участвующие в предоставлении услуг), продукты (технологии и управление), процессы (роли и виды деятельности), партнеров (производители, разработчики). На выходе этот этап предполагает формирование пакета документов, именуемого Service Design Package (SDP), содержащего подробную проектную спецификацию. SDP будет руководящим документом при выборе решения на стадии преобразования.

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

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

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

      Таким образом, ITIL приводит к налаживанию связей между IT и клиентскими потребностями, что выражается в улучшении предоставляемых услуг и повышении удовлетворенности клиентов. Это ведет к снижению затрат за счет увеличения эффективности использования ресурсов. Например, согласно исследованию Gartner, ряд японский компаний, использовавших процесс ITIL, сумели снизить влияние человеческого фактора в управлении релизами на 20% в год и сократить расходы на производство на 30% за три года. Кроме того, методы ITIL позволяют сформировать прозрачность при работе с IT-активами и более стабильные условия для поддержки постоянных изменений бизнеса.

      Что такое ITIL?

      ITIL расшифровывается как библиотека IT-инфраструктуры, которая появилась в 80-х годах. Бренд ITIL принадлежит Axelos.

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

      Структура ITIL разделена на 5 основных томов:

      • Стратегия обслуживания
      • Проектирование услуг
      • Сервисный переход
      • Сервисное обслуживание
      • Постоянное улучшение обслуживания

      За эти годы было много итераций в рамках ITIL; ITIL V4 является последним в линейке. В последней версии они имеют:

      • Учитывая важность ценности, результата, стоимости и риска.
      • Определены 4 аспекта управления услугами.
      • Внедрил концепцию, называемую ITIL Service Value System.

      Помимо того, что ITIL является основой, ITIL предоставляет важные термины, такие как База данных управления конфигурацией (CMDB), Элемент конфигурации (CI), Управление инцидентами, Управление проблемами, Управление изменениями и т. Д.

      Преимущества ITIL

      Вот некоторые из преимуществ наличия структуры ITIL:

      • ITIL значительно сокращает время принятия ITSM.
      • Уверен, что ваши ИТ соответствуют вашему бизнесу.
      • Это помогает вам управлять бизнес-рисками из-за перебоев в обслуживании.
      • Он устанавливает стандарт для профессионалов ITSM.

      Что такое ITSM?

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

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

      Преимущества ITSM

      Вот некоторые преимущества внедрения ITSM:

      • Удовлетворенность клиентов за счет лучшего обслуживания.
      • Хорошо продуманные рабочие процессы, которые приводят к повышению эффективности.
      • Дает вам возможность определить причину проблемы.
      • Снижает стоимость предоставления услуг за счет правильного использования ресурсов.

      Так в чем же разница?

      ITIL ITSM
      ITIL - это структура, которая учит лучшим практикам ITSM. ITSM объединяет ITIL с бизнес-целями для предоставления ИТ-услуг
      Основное внимание уделяется ИТ Основное внимание уделяется бизнесу
      Структура, которая рассказывает, как предоставлять услуги Методология, чтобы выяснить, что предоставлять в качестве услуг
      ITIL занимается только предоставлением ИТ-услуг Внедрение ITSM влияет на организацию в целом

      Что было раньше: ITSM или ITIL?

      В отношении двух ключевых понятий сервисного подхода применима известная дилемма яйца и курицы — что первично? Чтобы объяснить взаимосвязь ITSM и ITIL, Стюарт Рейнс (Stuart Rance) из IT-компании BMC написал статью «ITSM vs. ITIL: What’s the Difference?». Она начинается с четкого разграничения области применений и формулировки ключевого утверждения: между ITSM и ITIL невозможно поставить союз «или». И вот почему.

      Если перенести эти понятия в бытовую плоскость, ITSM можно сравнить с подходом к работе бара, все процессы которого в первую очередь сосредоточены на вкусах, предпочтениях и удобстве клиента. Тогда книга о клиентском подходе в барном деле Джона Таффера (Jon Taffer), американского консультанта и писателя, — это ITIL.

      Иначе говоря, ITSM — это способ ведения IT-бизнеса, а ITIL — лучшие практики. Однако — и это важно — ITIL является не признанным стандартом, но основой, которая содержит передовые практики, а не пошаговую инструкцию обязательную к выполнению. По словам Стивена Вейла (Steven Weil), старшего консультанта по безопасности в консалтинговой компании Seitel Leeds & Associates, «ITIL не содержит конкретных, подробных описаний того, как процессы должны быть реализованы, так как они будут отличаться в каждой организации. Другими словами, ITIL сообщает предприятию, что делать, но не как это делать».

      Получается, согласно смыслу, заложенному в эти два понятия, сперва зародилась сама мысль о сервис-ориентированном IT, которая позже стала причиной появления упорядоченной системы поддержки.

      Читайте также: