Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
По сравнению с человеческим фактором вспомогательными элементами структуры SLM являются формальная организация - создание каталога услуг, фиксация обязательств и контроль их исполнения. Хотя эти элементы важны, ключевое значение имеет наличие и взаимодействие ответственных людей с обеих сторон. Без правильных людей, понимающих свою ответственность и эффективно взаимодействующих между собой, формальные структуры не обеспечат успешного результата.
В ITIL Service Design примеры SLA и OLA очень похожи потому, что содержательно эти документы практически не отличаются. OLA формально описывает внутренние обязательства, которые поддерживают выполнение SLA, но структура и содержание этих документов таковы, что их можно заменить друг на друга без потери смысла. Это свидетельствует о том, что нет принципиальной разницы между SLA и OLA, а различие заключается лишь в том, с чьей точки зрения рассматривается документ. Отсюда следует, что термин OLA не добавляет существенной ценности и может быть избыточным.
Оптимальный размер задач в организации определяется критерием, при котором вероятность необходимости смены приоритетов минимальна. Чем меньше средний размер задачи, тем лучше, так как небольшие задачи быстрее завершаются и приносят ценность, что снижает риск их превращения в 'проблемные' и необходимость смены приоритетов. Оптимальный размер - такой, чтобы задача завершалась достаточно быстро, чтобы успеть принести ценность до возможного изменения обстоятельств, но не настолько мелкий, чтобы административные издержки управления не стали чрезмерными. Для определения этого размера необходимо анализировать исторические данные по скорости выполнения различных типов задач, учитывать цикл обновления приоритетов и стремиться к тому, чтобы большинство задач завершалось за период, который существенно короче, чем типичный интервал времени между изменениями внешних условий и потребностей бизнеса.
В тексте приведен пример с копанием канавы: владелец процесса определяет задачу ('Надо выкопать канаву вооон от того забора до завтрашнего обеда'), а менеджер процесса отвечает за её выполнение — покупает лопаты, следит за работой копателей и контролирует сроки. Этот пример помогает понять разницу между стратегическим управлением (владелец) и оперативным выполнением (менеджер).
Уровень компетенций координаторов изменений должен быть выше, чем у персонала при управлении инцидентами, по нескольким причинам: - Степень неопределенности: управление изменениями сопряжено с более высокой степенью неопределенности по сравнению с управлением инцидентами. Координаторам изменений необходимо самостоятельно проводить анализ влияния, оценку рисков и стоимости, что требует более углубленных профессиональных знаний. - Анализ влияния: координаторы изменений должны понимать сложные взаимосвязи между системами и бизнес-процессами, чтобы оценить потенциальное влияние изменений, тогда как при управлении инцидентами часто используются готовые процедуры и шаблоны. - Принятие решений: координаторы изменений имеют больше полномочий для принятия решений в процессе реализации изменений, что требует от них хорошего понимания всего ИТ-ландшафта и бизнес-процессов организации. - Требования к планированию: управление изменениями требует умения правильно спланировать этапы реализации, оценить временные и ресурсные затраты, тогда как при управлении инцидентами фокус преимущественно на оперативном восстановлении сервиса. - Качественная оценка рисков: координаторы должны уметь качественно оценивать риски изменений, определять необходимость дополнительных согласований и этапов проверки, что требует более высокого уровня технических и управленческих навыков. - Управление сложными взаимодействиями: процесс внедрения изменений часто включает координацию работы нескольких команд и подразделений, что требует от координатора хороших навыков коммуникации и управления проектами. Поэтому координаторы изменений должны обладать не только техническими навыками, но и достаточно глубоким пониманием бизнес-целей и процессов организации.
Приоритет проблемы может изменяться в течение времени, если к ней привязываются новые инциденты. Факт привязки новых инцидентов увеличивает суммарный вес проблемы, что может повысить её приоритет. Это требует постоянного пересмотра приоритетов проблем в ходе их расследования и устранения.
Обучение сотрудников может исключаться из ITSM-проектов по нескольким причинам: недостаток бюджета, отсутствие веры в результативность обучения, или ложное представление о том, что автоматизация процессов и систем сама решит все проблемы без изменения поведения персонала. При этом консультанты и интеграторы активно обучаются, тогда как внутренние сотрудники заказчиков часто остаются без необходимой подготовки, что влияет на успешность проекта.
Сквозная автоматизация в массовом производстве позволяет сократить издержки на оплату труда, снизить число дефектов и оптимизировать производственные процессы, что делает возможным конкурировать по цене с дешевым трудом, сохранив при этом высокий уровень качества продукции. Кроме того, автоматизация обеспечивает большую гибкость производства для кастомизации продуктов под индивидуальные запросы клиентов без значительного увеличения общей стоимости.
Повышая приоритет одной задачи, мы автоматически снижаем приоритет всех остальных задач в системе, что приводит к их отложению и уменьшению выделяемых на них ресурсов. Этот процесс часто игнорируется, несмотря на то что отложенные задачи могут иметь своих заинтересованных лиц с собственными ожиданиями. Регулярная смена приоритетов создает турбулентность в системе выполнения работы, приводя к потерям и замедлению общего выполнения всех задач. Это происходит потому что при частой переброске ресурсов между задачами теряется ритм работы, а незавершенные задачи становятся потерянными затратами, поскольку не приносят никакой ценности.
Главным фактором успеха выступает наличие профессионального опыта у архитектора и участников проекта. Однако важно применять этот опыт с адаптацией под специфические потребности заказчика, так как без критической оценки стандартные подходы могут привести к ошибкам из-за неправильной интерпретации контекста конкретной организации.