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

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

25
авторов

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

100%
оригинальный контент
Проектируемый простой услуг (Projected Service Outage, PSO) - это документ, в котором фиксируются все запланированные периоды недоступности услуг, необходимые для реализации изменений. За формирование и актуализацию этого документа в первую очередь отвечает процесс управления изменениями. Однако при согласовании поправок в графике плановых простоев также участвуют процессы управления уровнем услуг (Service Level Management, SLM) и управления доступностью (Availability Management), обеспечивая комплексный подход к планированию и минимизации влияния простоев на бизнес.
Процесс SLM можно определить как дееспособный по наличию и реальным действиям ответственных лиц за услугу с обеих сторон - и со стороны заказчика, и со стороны поставщика. Если такие люди найдены, включены в работу и демонстрируют понимание своей ответственности, а также выстроили эффективное взаимодействие между собой, то это является основным показателем работоспособности процесса SLM. Формальные элементы, такие как каталог услуг или контроль исполнения, являются второстепенными по сравнению с этим критерием.
В контексте организационных изменений менеджеры и лидеры различаются по своим подходам и компетенциям. Менеджеры обучаются "работать по процессу", эффективно использовать ресурсы, управлять конфликтами, добиваться заранее обозначенных результатов по заданным KPI с определенной частотой. Лидеры же способны работать в условиях неопределенности, идти на риски, проверять на прочность существующий порядок. Они создают привлекательную картину будущего и могут увлечь сотрудников этой идеей, обеспечивая мотивацию для изменений. Для успешной реализации масштабных организационных преобразований необходимы именно лидеры, а не только менеджеры, так как изменения требуют выхода за рамки установленных процессов и адаптации к новым, пока не определенным условиям.
При введении OLA внутри ИТ-подразделения могут возникнуть следующие проблемы: создаётся риск излишней автономности внутренних подразделений, так как отношения с ними будут строиться как с внешними поставщиками услуг, но без аналогичных средств влияния (конкуренции, денежных расчетов или административного влияния); потребуется серьезная переработка всех процессов, в которые вовлечено внутреннее сервисное подразделение; возникнет задача контроля исполнения обязательств внутренними поставщиками, которая осложняется множественностью связей между потребителями и поставщиками; возможно, понадобятся изменения в организационной структуре, поскольку потребуется арбитр — третья сторона, обладающая функцией контроля и соответствующими полномочиями. Эти последствия нужно учитывать и оценивать при решении о внедрении OLA.
Наличие дефектов негативно влияет как на бизнес, так и на процесс разработки. Со временем дефекты приводят к экспоненциальному росту потерь - в примере из деловой игры 'Проект Феникс' потери составили 2 000 долларов в первом раунде, 26 000 во втором и 39 000 в третьем. Наличие дефектов замедляет разработку новых функций, так как разработчики вынуждены тратить время на исправление ошибок, и создает технический долг, который становится все дороже в исправлении. Для бизнеса это трансформируется в прямые финансовые потери и ухудшение качества продукта, что отражается на удовлетворенности клиентов.
Точная постановка задачи, полученная в результате предпроектного обследования, предоставляет несколько ключевых преимуществ: она позволяет создать обоснованный и убедительный план проекта для руководства заказчика, снижает риски непредвиденных изменений в процессе реализации, оптимизирует использование ресурсов и бюджета, а также создает основу для эффективного управления проектом. В результате проект становится более управляемым и предсказуемым.
Нормировать в процессе управления проблемами можно фазу диагностики (problem control - PC), но не всю обработку проблемы целиком. Нормирование проводится на основании уровня влияния проблемы на бизнес-процессы. Например, для проблемы с высоким уровнем влияния срок диагностики может быть установлен в 1 неделю, для среднего уровня - 2 недели, и так далее. Это обосновано тем, что диагностика проблемы, определение корневой причины и вариантов решения имеет более предсказуемый временной контур по сравнению с последующей реализацией решения.
Первый способ, при котором обращение остается на первой линии, а на вторую назначается задание, может быть менее эффективным из-за нескольких факторов. Возникает риск потери важной информации между основным обращением и заданиями, усложняется отслеживание полного статуса решения инцидента, так как информация рассредоточена между основной записью и заданиями. Кроме того, ответственность за решение может быть нечетко распределена, что может приводить к замедлению процесса решения проблемы. Этот метод требует более сложной координации при работе со сложными инцидентами, требующими участия нескольких групп.
Чтобы определить, какие этапы обработки задач являются лишними и не добавляют ценности, нужно ответить на вопрос: создает ли этот этап фактическую ценность для конечного пользователя или способствует её созданию? Если этап не добавляет ценность и не улучшает качество результата (например, двойные проверки без ясной цели), он стоит на анализу. Важно спросить: чем обусловлена необходимость дополнительной обработки? Если это не обучение или не снижение значимых рисков, то этап, вероятно, лишний. Также помогает анализ количества ошибок – если их мало, то строгий контроль может быть избыточным.
Процесс BRM в ITIL Service Strategy выполняет три ключевые функции: 1) Установление и поддержание отношений между сервис-провайдером и заказчиком на основе глубокого понимания бизнес-потребностей заказчика; 2) Помощь заказчику в определении ценности получаемых ИТ-услуг и понимании того, как эти услуги поддерживают его бизнес-цели; 3) Определение текущего и будущего спроса на услуги, а также обеспечение возможности сервис-провайдера удовлетворять эти потребности в различных условиях. BRM фокусируется именно на отношениях и удовлетворенности заказчика, в отличие от других процессов ITIL, которые сосредоточены преимущественно на техническом обеспечении качества услуг.