Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
В контексте предоставления услуг 'utility' (полезность) и 'warranty' (гарантия) обозначают два ключевых аспекта услуги. 'Utility' связан с функциональной полезностью услуги — например, в случае горячего водоснабжения это достаточная температура воды, правильный напор и удобное расположение крана для стирки. 'Warranty' касается качества и надежности услуги — например, режим подачи горячей воды (круглосуточно или с перерывами), скорость реагирования на аварии, длительность профилактических отключений и безопасность состава воды для здоровья. Гарантии должны быть тщательно проработаны поставщиком, согласованы с клиентом, а затем подтверждены в ходе предоставления услуги.
В повседневной практике стандартные изменения часто инициируются через запросы на обслуживание, поскольку многие запросы предполагают выполнение стандартных задач, таких как установка ПО или изменение прав доступа. Однако важно понимать, что запрос на обслуживание — это лишь средство инициации, а само по себе изменение должно соответствовать критериям стандартного изменения: быть низкорисковым, документированным и предварительно авторизованным. В организациях часто возникает путаница, когда запрос на обслуживание ошибочно отождествляют со стандартным изменением, что может привести к потере контроля за изменениями.
Связи между элементами CMDB должны содержать атрибуты и логику, которые позволяют переносить потребность в мощностях от ресурсов верхнего уровня к поддерживающим ресурсам. Например, если верхний уровень требует определённого объёма вычислительных мощностей или объёма хранимых данных, эта потребность должна быть корректно распределена между всеми связанными ресурсами. В обратном направлении, связи передают стоимость обеспечения каждой единицы мощности, что позволяет отслеживать экономику сервиса. Это делает возможным анализ как текущих, так и будущих потребностей в мощностях и ресурсах.
Ключевые ошибки включают дублирование информационных этапов, например, лишнее упоминание о важности звонка без последующих действий; несоответствие контента IVR реальной ситуации (сообщение о переводе на специалиста при фактическом нахождении в очереди); отсутствие фильтрации звонков по типу клиента, из-за чего клиенту приходится слышать сообщения, не относящиеся к его статусу; неоправданно длительные паузы из-за непрозрачности статуса запроса; запросы оценить обслуживание до завершения взаимодействия с оператором; разобщённость уровней поддержки, приводящая к повторному изложению проблемы; игнорирование технических ограничений (например, обрыв связи при долгом ожидании) без компенсационных мер.
Запрос на обслуживание по своей сути не является стандартным изменением, хотя стандартные изменения часто могут инициироваться как запросы на обслуживание. Стандартное изменение — это тип изменения с низким риском, предварительно авторизованное и документированное, тогда как запрос на обслуживание — это механизм выполнения определенной задачи, такой как установка ПО или изменение прав. Стандартные изменения могут быть частью процесса обращения с запросами на обслуживание, но запрос на обслуживание сам по себе не эквивалентен изменению. Это распространенное заблуждение, возникающее из попытки упростить коммуникацию и процессы.
Отношения между процессами управления релизами и управления изменениями зависят от выбранной организационной модели: в первом подходе (подразделение разработки) управление релизами самостоятельно обрабатывает нестандартные запросы на изменения и может выступать до управления изменениями, а стыкуется с ним на этапе передачи релиза в эксплуатацию; во втором подходе (подразделение эксплуатации) управление релизами является инструментом управления изменениями, отвечающим именно за внедрение, а не за авторизацию изменений. Управление изменениями выдает задания управлению релизами по внедрению уже авторизованных изменений, а управление релизами отчитывается о результатах внедрения.
При работе с негативно настроенными клиентами эмпатия проявляется через умение искренне слушать и признавать чувства клиента. Важно не прерывать клиента, дать ему возможность высказаться, так как часто проблема частично решается уже после того, как человек чувствует, что его услышали. Эмпатия выражается также в умении контролировать собственные эмоции даже в напряженных ситуациях, избегать обесценивания проблем клиента и не предлагать решение раньше времени. Вместо этого нужно признать ошибку или проблему, если она действительно имеет место, и выразить готовность ее решить. Корректное обращение к клиенту по имени и извинения от имени компании могут значительно снизить негативное настроение. Эмпатия в такой ситуации создает атмосферу доверия и сотрудничества, а не противостояния, и помогает найти взаимоприемлемое решение, часто через вовлечение клиента в процесс поиска решения.
Для эффективной подготовки к деловым переговорам следует: детально изучить требования и возможные возражения другой стороны; проработать набор компромиссных решений на каждый спорный вопрос; подготовить четкое обоснование своей позиции с документальным подтверждением и примерами из практики; убедиться, что на переговоры приглашены лица, имеющие полномочия принимать решения; подготовиться к использованию общей терминологии; настроиться на позитивный и конструктивный диалог вместо противостояния.
Владелец процесса отвечает за соответствие процесса его назначению, занимается постановкой процесса, разработкой политик и стандартов, определением целевых показателей для процесса и обеспечивает стратегическое направление. Менеджер процесса отвечает за операционное управление процессом - планирование, координацию активностей, управление исполнителями, мониторинг и отчётность. Владелец процесса больше занимается стратегическими аспектами, определяя 'куда идём', тогда как менеджер процесса обеспечивает ежедневное функционирование процесса. Роль менеджера процесса может быть совмещена с ролью владельца процесса.
Да, подход MVP может эффективно помочь в выявлении избыточных элементов в существующих практиках. При сравнении реального охвата практики с её минимальной жизнеспособной версией становится видно, какие элементы не участвуют в создании ценности текущих потоков. Эта деятельность, оставшаяся 'за бортом' MVP, требует анализа: если она не создает ценность для бизнеса, такой элемент можно исключить, что повысит общую эффективность организации и сократит затраты ресурсов на ненужные операции.