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

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

25
авторов

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

100%
оригинальный контент
Операционный Уровневый Договор (OLA) предполагается как документ, который определяет обязательства внутреннего подрядчика по отношению к поставщику услуг, который тот предоставляет своим заказчикам (при этом между поставщиком и заказчиком заключены SLA). Однако, если внимательнее рассмотреть суть OLA, то оказывается, что с точки зрения подрядчика OLA на самом деле является SLA. То, что для одного субъекта выглядит как OLA, для другого может быть SLA, потому что предоставляется услуга, поддерживающая выполнение операций и обеспечение услуг внешним клиентам. Это значит, что OLA как отдельный документ не существует, а является SLA с точки зрения другого участника сервисных отношений.
Проектная деятельность фокусируется на краткосрочных целях и конечном результате, после чего команда обычно переходит к новым задачам. Однако без постоянной поддержки и развития процессов, которые были созданы в рамках проекта, их эффект может со временем исчезнуть. Даже успешные проекты требуют долгосрочного сопровождения, иначе достигнутые результаты не укоренятся в организации.
Качество первой линии поддержки напрямую влияет на общее восприятие услуги, так как это первая точка контакта с клиентом в случае возникновения проблем. Плохая работа первой линии приводит к формированию негативного впечатления о всей компании, даже если основные услуги качественные. Клиенты запоминают негативный опыт взаимодействия при решении проблем, часто об этом рассказывают другим и делятся в социальных сетях, что усугубляет негативное восприятие бренда. Качественная же первая линия поддержки, напротив, даже при возникновении проблем демонстрирует заботу о клиенте, что может превратить негативный опыт в положительное восприятие компании. От того, насколько быстро и профессионально решается первая проблема клиента, часто зависит его решение продолжать пользоваться услугами компании или перейти к конкуренту.
Время руководителя нужно беречь, так как оно критически ограничено, и его катастрофически не хватает на все задачи. Эффективное управление предполагает, что руководитель должен сосредоточиться на стратегических задачах и принятии ключевых решений, а не на оперативном выполнении задач, которые могут быть делегированы. RACI-матрица помогает определить, какие задачи (обозначенные как R - Responsible) могут быть переданы другим сотрудникам. Делегирование позволяет руководителю оптимизировать использование своего времени, повысить личную продуктивность и дать возможность подчиненным развивать профессиональные навыки. Это также способствует созданию более устойчивой команды, не зависящей от прямого участия руководителя в каждой задаче.
COBIT5 может быть адаптирован для конкретных организационных потребностей путем группировки процессов в более крупные блоки, как это было сделано в Бахрейне. Организация может оценить важность и эффективность каждого блока процессов и определить направления для улучшения, создавая дорожную карту для развития ключевых ИТ-процессов.
Должность пользователя влияет на уровень ИТ-услуг, так как для должностных VIP-персон могут быть предусмотрены специальные условия, такие как сокращенное время реакции технической поддержки или круглосуточная доступность услуг. Это обусловлено важностью конкретных сотрудников для бизнес-процессов организации.
Традиционная схема оценки влияния инцидентов имеет несколько существенных недостатков: 1) Сотрудник может не знать, испытывают ли его коллеги аналогичные проблемы, что затрудняет оценку масштаба инцидента. 2) Не существует четкой границы между 'совсем не работает' и 'частично не работает' - пользователь, столкнувшийся с проблемой печати отчета, вряд ли согласится, что эта проблема малозначительна, даже если остальные функции работают нормально. 3) Базовая схема не учитывает критичность определенных ИТ-услуг в конкретные периоды времени или для определенных групп пользователей.
Вебинары сложнее из-за отсутствия прямого визуального контакта с аудиторией, что затрудняет определение момента для вопросов и ответов. Участники вебинаров могут непрерывно отправлять вопросы в чат, требуя постоянного внимания к нему, в то время как при очном обучении тренер может физически видеть, когда люди хотят задать вопрос, и регулировать этот процесс. Также вебинары требуют дополнительного контроля за техническими аспектами (например, проверки, видят ли участники демонстрируемый материал), и сложнее отслеживать, понимают ли слушатели информацию, так как нет невербальных сигналов.
Если компания начинает вести себя невежливо или неприветливо, когда возникает нештатная ситуация, клиент ощущает, что его считают источником проблем. Это проявляется в недостатке внимания к его интересам, угрозах финансовых последствий и общей негативной атмосфере при решении вопроса. Как результат, вместо укрепления взаимных отношений компания теряет клиента, снижая его лояльность и повышая риск того, что он не только перестанет использовать их услуги, но и поделится негативным опытом с другими людьми. Поведение в сложные моменты служит индикатором реального отношения к клиентам.
В контексте ИТ-услуг слово «менеджер» часто не отражает суть должности и имеет формальный характер. Слово «управляющий» точнее передает значение этой роли, так как предполагает реальное влияние на процессы, системы и людей. Например, менеджер по продажам и управляющий отелем: первое название часто связано с операционной деятельностью, тогда как второе подразумевает более широкие полномочия и ответственность. В управлении ИТ-услугами важно, чтобы роль предполагала возможность принимать решения и влиять на процессы за пределами собственной компетенции, что больше соответствует понятию «управляющий».