Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.

6170+
вопросов и ответов

25
авторов

440+
источников

100%
оригинальный контент
Этап согласования снижает риски несанкционированного предоставления доступа, внесения изменений в систему без одобрения ответственных лиц, а также ошибок при выполнении запросов. Согласование позволяет проверить обоснованность запроса, соответствие его политикам безопасности и регламентам организации. Особенно важен этот этап при работе с ключевыми системами и данными, где ошибки могут привести к серьезным последствиям, таким как утечки информации или нарушение работы критически важных сервисов. Таким образом, согласование служит важной мерой контроля и повышает безопасность ИТ-инфраструктуры.
К менеджеру по управлению проблемами предъявляются следующие требования: глубокое понимание продуктов, архитектуры, конфигурации и взаимозависимостей; хорошие аналитические навыки, включая знание методологии исследования проблем и умение выстраивать коммуникации; способность находить оптимальные решения и добиваться результатов; умение координировать работу различных специалистов. Помимо технических знаний, менеджер должен уметь анализировать отчеты, выявлять тренды, обнаруживать закономерности и предлагать решения для устранения корневых причин проблем.
К запросам на обслуживание относятся все предопределенные инициируемые пользователями обращения, поддерживающие согласованное качество услуги. Это включает в себя: запросы на выполнение сервисных операций (например, замена картриджа), запросы информации (консультации), запросы на предоставление ресурсов (доступ к информационной системе), а также обратную связь в виде жалоб или благодарностей. Эти обращения носят предсказуемый характер, могут быть запланированы и часто поддаются стандартизации и автоматизации в рамках стандартного рабочего процесса.
Проблемы интеграции проявляются в следующих аспектах: различиях в детализации учёта финансов между системами, в системах учёта договоров может отсутствовать спецификация с перечнем позиций, в бухгалтерских системах может не учитываться нематериальные активы, инфраструктурные объекты могут группироваться в комплекты с описанием в текстовом комментарии. Это создаёт сложности при попытке получить точные данные по затратам на конкретную конфигурационную единицу. Также сложности возникают при сверке данных, особенно если есть договоры в иностранной валюте, которые требуют конвертации и учёта колебаний курса. Все эти проблемы делают процесс обеспечения консистентности данных сложным и требующим специальных решений.
Книга рассматривает основы сервисных отношений между ИТ и бизнесом, подчеркивая необходимость перехода от технического подхода к бизнес-ориентированному. Основной концептуальный элемент - это каталог ИТ-услуг, который служит мостом между бизнес-потребностями и ИТ-возможностями. Вводится понимание ИТ-услуги как ценности для бизнеса, а не просто как технического компонента. Книга обсуждает необходимость формирования четких ожиданий через SLA, управления взаимоотношениями с заказчиками услуг, оценки удовлетворенности бизнеса и позиционирования ИТ как внутреннего поставщика услуг. Особое внимание уделяется важности понимания бизнес-процессов и связи ИТ-услуг с их поддержкой.
Из концепции уровней зрелости в COBIT можно сделать следующие практические выводы: во-первых, уровень зрелости процесса следует рассматривать только как иллюстративный инструмент для визуализации текущего состояния или разницы между текущим и целевым состояниями процесса; во-вторых, нецелесообразно ставить в качестве цели проекта достижение конкретного уровня зрелости, аналогично тому, как бесполезно формулировать задачу как «купить продуктов на N рублей» без указания конкретных продуктов; в-третьих, при оценке процессов необходимо фокусироваться на конкретных контролирующих мероприятиях, а не на абстрактных уровнях зрелости.
При обработке сложных запросов, требующих работы нескольких групп (например, организация нового рабочего места), второй способ организации работы линий поддержки предоставляет значительные преимущества. Поскольку инцидент назначается непосредственно на вторую линию, это обеспечивает более четкое распределение ответственности и упрощает отслеживание процесса решения. Сложные запросы, которые могут проходить через несколько специализированных групп, легче управлять при полной передаче инцидента, так как уменьшается риск потери информации и дублирования действий, возникающих при использовании систем заданий, где основное обращение остается на первой линии.
Чтобы данные учета трудозатрат были полезны для управленческих решений, необходимо: четко определить цели сбора данных; выбрать простой и удобный метод учета, желательно ручной; обучить сотрудников правильно фиксировать время и классифицировать деятельность; не привязывать мотивацию к точности отчетов; анализировать данные в разрезе типов деятельности, а не отдельных сотрудников; фокусироваться на выявлении тенденций и узких мест, а не на микроуправлении каждым сотрудником; регулярно пересматривать и корректировать подходы к учету на основе обратной связи от сотрудников.
Сервисные отношения — это взаимодействие между поставщиком услуг и заказчиком, основанное на доверии, сотрудничестве и общих целях. SLA является одним из инструментов, поддерживающих такие отношения, так как фиксирует договоренности о требованиях к услуге и ожидаемом уровне. Однако успешные сервисные отношения не ограничиваются SLA: они зависят от человеческого фактора, взаимной вовлеченности и способности сторон совместно решать проблемы. SLA помогает структурировать отношения, но не заменяет качественное взаимодействие.
Использование традиционного подхода к визуализации деления задач на части приводит к созданию изолированных компонентов, которые не формируют целостный продукт. Например, если рассматривать слона как набор отдельных частей (уха, ноги, хвоста), то на промежуточных этапах невозможно проверить работоспособность системы в целом. Это увеличивает риск того, что компоненты не будут корректно взаимодействовать, а также делает процесс разработки негибким и трудноадаптивным к изменениям. Кроме того, такой подход затрудняет получение обратной связи от пользователей и выявление критических ошибок на ранних этапах.