Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Статус «Срочно» в деловом письме следует применять умеренно и только по реальной необходимости, так как злоупотребление этим статусом приведет к его обесцениванию. Если статус «Срочно» будет использоваться слишком часто, коллеги начнут относиться к таким письмам как к стандартным задачам, и срочность перестанет быть заметной. Обычно ответы на письма со статусом «Срочно» должны приходить в течение нескольких часов до конца рабочего дня. Перед применением статуса «Срочно» необходимо убедиться, что запрос действительно требует немедленного внимания и что задержка с ответом может привести к негативным последствиям для проекта или компании.
Для корректной работы автоматической эскалации заявок в условиях major-инцидентов необходимо предусмотреть исключения из общих правил. Эти исключения должны предотвращать автоматическую передачу заявок на следующие уровни поддержки, когда инцидент имеет статус major и обрабатывается как часть единого инфраструктурного события. Также может потребоваться автоматическое приостановление таймеров эскалации для всех заявок, относящихся к конкретному major-инциденту, до момента его закрытия. Дополнительно можно внедрить механизм групповой обработки, который позволяет временно отменять индивидуальные SLA для заявок, связанных с крупными инцидентами, так как они разрешаются комплексно, а не по отдельности.
В традиционной системе KPI, где оценка основана только на соблюдении максимального времени Tmax, решение инцидента сразу перед истечением срока (например, за 3 часа 55 минут при Tmax = 4 часа) дает полный балл. Это создает обратную мотивацию — исполнители могут откладывать решение до последнего момента, не стремясь к оперативному восстановлению сервисов, что приводит к ненужным простоям и ущербу для бизнеса, хотя формально все нормативы соблюдены.
Делегирование функций локальным командам в распределенных структурах позволяет значительно сократить время обработки обращений, так как исключаются задержки, связанные с ожиданием работы команды из другого часового пояса. Локальные специалисты могут оперативно реагировать на запросы пользователей в своем регионе, что повышает скорость и качество обслуживания. Кроме того, локальные команды лучше понимают специфику региона и могут учитывать местные особенности при решении задач. Это также снижает нагрузку на центральные группы и позволяет им сосредоточиться на более сложных или стратегических задачах. Делегирование функций укрепляет автономность региональных подразделений и повышает общий уровень удовлетворенности пользователей.
Как определить границы между общим регламентом и спецификой выполнения этапов для разных участников?
Границы между общим регламентом и спецификой выполнения этапов определяются по следующему принципу: общий регламент включает те элементы процесса, которые являются обязательными для всех участников и не зависят от специфики их работы - это общие этапы, точки контроля, порядок следования действий. Специфика выполнения этапов относится к тем аспектам, которые могут различаться в зависимости от возможностей, ограничений или особенностей участников. Например, в процессе управления изменениями общим регламентом будет последовательность этапов согласования, разработки и публикации, а спецификой - методы согласования (количество уровней), длительность разработки и правила публикации (немедленно, по релизной схеме), которые могут быть разными для разных типов информационных систем.
Склонность к риску определяет приоритеты в совершенствовании услуг. Организация с высокой терпимостью к рискам может сосредоточиться на инновациях и скорости внедрения, тогда как консервативная структура поставит во главу угла стабильность и безопасность. Например, больница не может позволить сбоев в работе систем, поэтому ее ИТ-услуги направлены на минимизацию рисков, в то время как стартапы могут выбирать гибкие, но менее стабильные решения.
Для обеспечения автоматизированного мониторинга пунктуальности прибытия с минутной точностью требуется дооснащение не менее чем 20% станций железнодорожной сети Великобритании. Это связано с необходимостью установки современной системы контроля времени прибытия и отправления поездов, которая сможет фиксировать отклонения с необходимой точностью на каждом остановочном пункте, а не только на конечной станции, как было раньше. Такое оборудование включает в себя как аппаратные средства для измерения времени, так и программное обеспечение для обработки и анализ данных.
Tmin определяется как время, в течение которого простои не оказывают измеримого влияния на бизнес-процессы, и устанавливается совместно с заказчиком на основе анализа критичности сервисов. Tmax формируется как компромисс между максимально допустимым простоем для бизнеса (часто близким к Tmin) и реальными возможностями ИТ-подразделения с запасом (как правило, значительно дольше). Например, бизнес может требовать восстановления за 30 минут (Tmin), тогда Tmax устанавливается в 4 часа, учитывая текущие возможности ИТ.
Автор сомневается в ценности аналитики Гартнера при выборе ITSM-решений из-за быстрого и непредсказуемого изменения позиций вендоров в магическом квадрате, не подкрепленного существенными изменениями в продуктах. Это вызывает вопросы о том, как компании могут опираться на такую аналитику для принятия решений о стратегических партнерах на годы вперед. Кроме того, критикуется концентрация на оценке поставщиков вместо технических характеристик продуктов, что приводит к усреднению и отставанию от реального состояния ITSM-рынка.
Для нахождения оптимального баланса необходимо смотреть на команду открытыми глазами и изучать ситуацию системно. Важно честно измерять показатели, доверять метрикам и наблюдениям за поведением пользователей. Каждая команда должна найти свою точку равновесия, учитывая особенности культуры, приложения, накопленного наследия и контекста. Этот баланс позволяет определить, сколько времени команда может уделять донесению реальной пользы до клиентов, сочетая разработку новых фич с решением текущих проблем и управлением техническим долгом.