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

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

25
авторов

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

100%
оригинальный контент
Наиболее эффективные подходы к организации работы команды в деловых играх включают объяснение команде не только того, что делать, но и зачем это нужно, какой результат требуется, чем хороший результат отличается от плохого. Эффективные руководители определяют приоритеты устранения недостатков, дают понять, почему одни задачи важнее других, и добиваются, чтобы команда сама определила, как именно устроить работу и взаимодействие. Они выделяют направления ответственности, назначают конкретных ответственных, определяют краткосрочные приоритеты, продолжают видеть общую картину и не погружаются полностью в детали выполнения задач.
Точная постановка задачи, полученная в результате предпроектного обследования, предоставляет несколько ключевых преимуществ: она позволяет создать обоснованный и убедительный план проекта для руководства заказчика, снижает риски непредвиденных изменений в процессе реализации, оптимизирует использование ресурсов и бюджета, а также создает основу для эффективного управления проектом. В результате проект становится более управляемым и предсказуемым.
Возвратное движение задач в потоке создания ценности является проблемой, потому что оно прерывает направленное движение работы к завершению, создает непредсказуемость в процессе и приводит к потере времени. Когда задачи возвращаются на предыдущие этапы, специалисты вынуждены переключаться между задачами, что требует дополнительных когнитивных затрат и снижает общую продуктивность. Некоторые процессы, такие как обязательное ревью кода на отдельном этапе, становятся источником неоправданных обратных движений, если они не обусловлены обучающими целями для молодых специалистов.
Заказчики обычно обращают внимание на три ключевых параметра качества услуги: функциональность, доступность и цену. Эти параметры формируют так называемую «полезность» услуги - видимую часть, за которую заказчики охотно платят и к которой умеют предъявлять конкретные требования. При этом заказчики редко обращают внимание на элементы, обеспечивающие «гарантию» услуги - невидимые процессы, которые гарантируют, что полезность будет предоставлена в оговоренных условиях. Это создает дисбаланс между тем, что заказчик видит и ценит, и тем, что фактически обеспечивает стабильную работу ИТ-службы.
Важно, чтобы инцидент возвращался именно той группе, которая предоставила решение, потому что только эта группа может исправить свои собственные ошибки и доработать инцидент корректно. Если же инцидент возвращается на обработку другой группе (например, Service Desk), то теряется ответственность за качество решения, и создается риск некачественной доработки, так как вторая группа может не обладать полным пониманием проблемы. Это также искажает метрику результативности, делая её менее точной.
Для описания процесса управления сервисными активами и конфигурациями рекомендуется создать один основной документ - "План управления сервисными активами и конфигурациями". В этом документе следует описывать комплекс процессов управления, а дополнительную информацию (структура CMDB, правила именования, требования к аудиту) выносить в приложения. Такой подход обеспечивает логичную структуру документа и избегает дублирования информации, которое возникает при разделении на два документа (например, отдельно регламент процесса и план управления конфигурациями) с последующей сложностью в поддержании согласованности между ними.
Все внеплановые простои, даже те, которые связаны с безотлагательными изменениями, следует включать в общую отчётность по доступности ИТ-услуг. Однако рекомендуется анализировать показатели доступности как с учётом таких простоев, так и без них, чтобы оценить реальное влияние экстренных изменений на общую доступность сервисов. Это позволяет отделить плановые и согласованные простой от непредвиденных сбоев и получить более полное представление о качестве предоставляемых услуг.
Процесс возврата средств должен быть организован следующим образом: при возникновении технической проблемы с оплатой система должна автоматически зафиксировать инцидент и уведомить клиента. Сотрудник поддержки должен иметь возможность инициировать процесс возврата средств или создать заявку, которая сразу направляется в соответствующий отдел (например, финансовый или технический). Клиенту должен быть присвоен уникальный номер заявки для отслеживания статуса обращения. Компания должна сообщить клиенту предполагаемые сроки решения проблемы и регулярно информировать о прогрессе. Если возврат средств невозможен автоматически, должен быть запущен ручной процесс с четкими сроками исполнения и обязательным уведомлением клиента о завершении операции. Кроме того, компания должна провести внутренний анализ причины проблемы для предотвращения ее повторения.
Обычно люди представляют иерархическую структуру услуг: на верхнем уровне находятся бизнес-услуги, предоставляемые заказчику для выполнения его бизнес-процессов, на среднем уровне — технические услуги, поддерживающие бизнес-услугу, а на нижнем уровне — компоненты ИТ-инфраструктуры. При этом OLA заключаются на технические услуги с такими параметрами, чтобы обеспечивать выполнение SLA для бизнес-услуг.
Преимущества телефонной связи для первой линии поддержки включают возможность детально расспросить пользователя и оперативно помочь ему в ходе разговора, а также прием большего числа обращений с меньшим количеством сотрудников. С точки зрения клиента, телефонный контакт удобен тем, что требуется запомнить только номер телефона, можно получить помощь сразу в ходе разговора и не требуется сложной технической подготовки для использования сервиса. Однако, при значительном потоке обращений может возникнуть проблема с дозвоном и необходимость круглосуточного дежурства сотрудников.