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

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

Централизованный элемент в модели RBAC (Role-Based Access Control) - это использование ролей. Именно на основания ролях строится вся система управления доступом. Роли представляют собой набор разрешений, которые позволяют пользователям выполнять определенные действия с различными ИТ-ресурсами. В RBAC доступ к ресурсам предоставляется не напрямую пользователям, а через роли, которые затем назначаются пользователям. Это обеспечивает более гибкое и эффективное управление доступом по сравнению с другими моделями.

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

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

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

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

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

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

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