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

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

25
авторов

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

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