Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Можно использовать опросник, основанный на перечне факторов, влияющих на количество обращений: отрасль бизнеса, тип предоставляемых услуг, сложность и количество услуг, частота обновлений, подходы к изменениям, технологические особенности ИТ-инфраструктуры, стандартизация среды, интенсивность использования ИТ, грамотность пользователей, наличие баз знаний, возраст устройств, тип работы (удаленный или нет), организационная структура и географическое распределение. Оценка по этим критериям позволяет прогнозировать нагрузку не только через количество пользователей, но и через анализ специфики организации.
Если запросы поступают мимо первой линии поддержки без регистрации в системе автоматизации, возникает «параллельная реальность» в управлении инцидентами. Это приводит к снижению ценности процесса управления инцидентами, так как нарушается прозрачность и полнота данных об инцидентах. Без регистрации обращений невозможно отслеживать их статус, анализировать корневые причины или формировать отчеты. Основные риски связаны с тем, что значительная часть инцидентов, связанных с нарушениями работы прикладного ПО, остается вне системы, что увеличивает общее время восстановления и снижает качество обслуживания бизнес-операций.
Неравномерное поступление инцидентов увеличивает среднее время их решения из-за эффекта очереди. Типичное распределение инцидентов похоже на 'верблюда' - с пиками нагрузки в определенные часы дня (обычно в первой половине). Когда инциденты приходят неравномерно, они попадают в очередь и вынуждены ждать своей очереди, даже если производительность персонала остается неизменной. В наихудшем случае, когда все инциденты приходят одновременно (например, утром), среднее время решения может возрасти в разы. Например, при 24 инцидентах, решаемых персоналом с производительностью 20 минут на инцидент, среднее время решения увеличивается с теоретических 20 минут до 4 часов 10 минут просто из-за эффекта последовательной обработки очереди.
Process Improvement Plan (PIP) - это план совершенствования процессов. При внедрении ITSM этот план претерпевает существенные изменения и расширяется, становясь планом совершенствования услуг (Service Improvement Plan, SIP). Теперь изменения процессов оцениваются именно с позиции их влияния на качество предоставляемых услуг, а не только с точки зрения оптимизации внутренних процессов.
Управление доступностью и управление непрерывностью тесно связаны, так как оба процесса ориентированы на обеспечение бесперебойной работы ИТ-услуг. В некоторых стандартах, таких как ISO/IEC 20000, они объединены в один процесс. Это обусловлено тем, что оба процесса направлены на предотвращение сбоев и минимизацию их последствий. Управление доступностью фокусируется на обеспечении требуемого уровня доступности услуг, а управление непрерывностью — на восстановлении услуг после инцидентов, связанных с непредвиденными простоями.
Основное отличие формулировок о стандартных изменениях между ITIL V3 и ITIL4 заключается в большей детализации в версии ITIL4. В ITIL V3 основной акцент делается на заранее авторизованный подход к выполнению, основанный на утвержденной процедуре. ITIL4 добавляет явное указание, что стандартные изменения являются изменениями с низким риском и могут внедряться без дополнительной авторизации для каждого конкретного случая. Также ITIL4 более подробно описывает процесс оценки рисков при создании или пересмотре моделей стандартных изменений, подчеркивая, что комплексная оценка рисков проводится на уровне процедуры выполнения, а не для каждого экземпляра изменения. Обе версии согласны в том, что авторизация требуется на этапе разработки модели стандартизованного изменения.
Необходимость в CI/CD может быть не столь очевидной для команды, которая разрабатывает программное обеспечение для будущего релиза, MVP или первой версии, который запланирован на значительный срок вперед (например, через полгода-год). В таких случаях основная проблема заключается не в организации процесса доставки изменений, а в самом создании работоспособного продукта. До тех пор, пока нет боевой среды с реальными живыми пользователями, внедрение сложного конвейера развёртывания может оказаться преждевременным и отвлекающим от основных задач разработки. В этой ситуации ресурсы команды лучше направить на создание качественного продукта, а вопросы автоматизации процессов доставки и развертывания можно решать уже тогда, когда будет определенность с пользовательской аудиторией и необходимостью частых обновлений.
Для привлечения внимания пользователей к новым ИТ-сервисам применяются различные методы: проведение PR-мероприятий, посвященных новым сервисам и интерфейсам; рекламные акции с выгодными условиями использования портала; инвестиции в адаптацию интерфейсов с всплывающими подсказками, предикативными технологиями поиска, обучающими видеоуроками в один клик; упрощение экранных интерфейсов; прямые ссылки на поддержку и базу знаний из корпоративных систем; тесная интеграция информационных систем в единое рабочее пространство для бизнес-ролей; сокращение объема и повышение доступности учебных материалов; создание специальных каналов коммуникации для кроссфункциональных групп; повышение востребованности информационных рассылок.
Три основные причины, почему "заложенные" в процесс KPI не очень хорошо работают: 1. Авторы KPI спроектированного процесса часто слепо копируют рекомендации из "умных" книг (ITIL, COBIT и другие), не учитывая, что приведенные там метрики являются лишь примерами для иллюстрации, а не готовыми решениями, подходящими для конкретной организации. 2. При внедрении KPI часто игнорируется здравый смысл, когда стремятся измерить всё подряд и отвергают субъективные данные (например, опросы удовлетворенности пользователей), хотя некоторые аспекты управления можно и нужно оценивать через удовлетворенность. 3. KPI отдельных процессов проектируются изолированно, без учета их взаимосвязей и места в общей системе управления ИТ. Это создает фрагментарную картину вместо комплексной системы оценки деятельности ИТ-подразделения.
Сервисное мышление — это особенное отношение к работе и предоставляемым услугам. Оно включает несколько компонентов: знание своих заказчиков/пользователей, понимание их ожиданий, фокусирование на ценности для заказчика, взятие на себя ответственности (включая бизнес-результаты), проявление эмпатии, осознание культуры и адаптацию к ней, способствование сотрудничеству и этичное поведение. Это не абстрактное понятие, а конкретный подход к принятию решений, который определяет, как сотрудник или организация взаимодействует с потребителями услуг.