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

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

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

Организация поддержки без единой точки контакта (Service Desk) позволяет снизить нагрузку на центральную службу, так как большая часть обращений напрямую попадает к профильным группам. Например, по данным описанных кейсов, около 81% обращений через электронные каналы взаимодействия, таких как электронная почта и веб-интерфейс, сразу направляются в соответствующие технические группы, а телефонные обращения, проходящие через первую линию, составляют лишь 19% всех обращений. Это обеспечивает более быстрое решение задач и оптимизацию процессов за счет специализации каждой группы.

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

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

Чтобы понять, есть ли в вашем потоке проблема с отложенными задачами, достаточно провести упражнение по картированию потока. Необходимо детально пройтись по каждому этапу потока, определить, какие из них создают ценность, а какие только создают задержки. Если в вашем потоке есть этапы, аналогичные 'Отложено' или 'Заблокировано', которые не добавляют ценности и позволяют задачам простаивать, это указывает на проблему. Также можно оценить, как много задач зависает на определенных этапах, какое время они там проводят и какие причины объявляются для задержек. В результате такого анализа станет понятно, превратился ли ваш поток в обычный бизнес-процесс.

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

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

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