Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Post-Implementation Review является неотъемлемой частью процесса управления изменениями в ITIL, служащим для оценки эффективности реализованных изменений и извлечения уроков. Он обеспечивает обратную связь в цикле улучшения услуг, позволяет определить соответствие результата поставленным целям и выявить области для дальнейшего совершенствования. Результаты PIR влияют на принятие решений по будущим изменениям, корректировку политик и процедур, а также на обучение команды.
Разделение учета инцидентов и запросов на обслуживание важно по нескольким причинам. Во-первых, инциденты искажают статистику по доступности услуги, если их смешивать с запросами. Во-вторых, со временем количество инцидентов должно снижаться благодаря улучшению качества системы и работе управления проблемами, тогда как запросы на обслуживание остаются стабильными или увеличиваются при росте пользователей. В-третьих, разделение позволяет правильно оценить объем экстренной работы по сравнению с плановой деятельностью, что критично для демонстрации заказчикам эффективности работы сервис-деска. В-четвертых, такой разделенный учет помогает лучше фокусироваться на анализе причин инцидентов и работе по их предотвращению, а не только устранению.
Игнорирование технического долга приводит к ряду серьезных рисков. Во-первых, значительно замедляется скорость разработки новых функций, так как инженеры тратят все больше времени на обходные пути и исправление ошибок в устаревшем коде. Во-вторых, возрастает количество багов и ошибок, что негативно сказывается на качестве продукта и удовлетворенности пользователей. В-третьих, технический долг может достигнуть критического уровня, при котором даже небольшие изменения требуют полной переработки больших фрагментов системы, что создает высокие затраты и риски срыва сроков. В-четвертых, падает мотивация и растет текучесть кадров среди инженеров, которые не хотят работать с устаревшим и плохо структурированным кодом. Наконец, игнорирование технического долга может привести к полной неспособности продукта удовлетворять новые рынки или требования, что ставит под угрозу бизнес в долгосрочной перспективе.
CMDB (Configuration Management Database) играет ключевую роль в оценке влияния major-инцидента на ИТ-услуги. С её помощью можно определить, каким пользователям и сервисам оказывается воздействие и насколько оно критично, что позволяет целенаправленно информировать затронутые группы и правильно оценивать последствия инцидента. Данные CMDB помогают установить причинно-следственные связи между компонентами ИТ-инфраструктуры и конечными сервисами, обеспечивая более точное управление инцидентом и снижение времени реагирования.
Вместо метрик типа 'доля своевременно решённых проблем' применяются: количество выявленных проблем через проактивный анализ, доля проблем, переведённых в известные ошибки, время на диагностику корневой причины, успешность внедрения решений (снижение повторных инцидентов), эффективность временных обходных путей. Эти показатели отражают специфику процесса — не скорость реакции, а качество анализа и долгосрочное улучшение стабильности сервисов.
Стандартные изменения играют важную роль в системе управления ИТ-услугами, обеспечивая предварительно авторизованные и детально документированные изменения с низким уровнем риска. Они позволяют автоматизировать и ускорить выполнение определенных процедур, сокращая время обработки запросов. Стандартные изменения часто инициируются через запросы на обслуживание, но их успешная реализация обеспечивается за счет разработки моделей, которые определяют четкие правила выполнения изменений. Это помогает повысить эффективность работы системы управления ИТ-услугами, позволяя фокусироваться на более сложных и рискованных изменениях.
Не стоит пытаться полностью внедрить ITIL как набор жестких правил. Вместо этого ITIL лучше рассматривать как набор рекомендаций и инструментов, которые можно гибко применять к конкретной ситуации. Не-ИТ организациям следует брать из ITIL именно те аспекты и процессы, которые соответствуют их бизнес-модели и потребностям. Например, если услуги организации основаны на деятельности персонала, а технологии вторичны, то будут наиболее полезны такие процессы, как управление уровнем услуг, управление инцидентами и управление знаниями. Гибкое использование ITIL вместе с другими подходящими инструментами даст более эффективный результат, чем попытка точного следования всем рекомендациям.
Подход с применением моделей изменений заключается в создании высокоуровневого процесса, состоящего из обязательных этапов, и описании деталей выполнения этих этапов для разных участников или систем в рамках моделей изменений. Это позволяет иметь единый регламент для всего процесса, но учитывать специфику выполнения отдельных шагов. Например, для управления ИТ-изменениями общий процесс может включать этапы: согласование функционального задания, разработка, тестирование, публикация изменений. А модели изменений позволяют задать специфические правила выполнения этих этапов для разных типов систем - проприетарных, самопальных, порталов и сайтов.
Возникновению неформальных лидеров в команде способствуют несколько факторов: личные качества участника (коммуникабельность, уверенность, способность принимать решения), опыт и знания в области проекта, а также способность вдохновлять и мотивировать коллег. Неформальный лидер часто появляется в группе, где есть разнообразие ролей, возрастных категорий и опыта работы, так как это создает основу для выделения наиболее компетентного или авторитетного участника. В команде, где сотрудники разных должностей, разных ролей, разного возраста и разного склада характера, как указано в тексте, обычно находятся один-два особо активных человека, которые достаточно быстро становятся неформальными лидерами. Этот лидер может возникнуть на любой игровой роли - как на формальной руководящей должности, так и на позиции, не предполагающей управления. Ключевой момент - способность этого человека брать на себя ответственность, предлагать решения и убеждать других следовать этим решениям.
Для успешного внедрения ITSM-проекта после смены руководства рекомендуется: провести презентацию проекта с акцентом на быстрый возврат инвестиций и уменьшение операционных затрат; подготовить отчет о достижениях проекта с конкретными метриками и примерами улучшений; организовать встречи с новым руководством для разработки четкого плана развития проекта, адаптированного под текущие бизнес-потребности; назначить куратора из числа опытных сотрудников для сопровождения проекта и демонстрации его ценности через решения конкретных бизнес-задач.