Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Для преодоления первоначальных сложностей при внедрении CI/CD рекомендуется составить карту или чек-лист технических практик, необходимых для реализации полноценного конвейера развёртывания. Следует осознать и обсудить, какие области требуют изменений, оценить текущий уровень и определить размер необходимых изменений ('разрыв'). После этого планомерно, ритмично и в рамках выделенного времени (например, 'налога в 20%') реализовывать изменения практических подходов. Рекомендуется также заранее договориться о желаемых параметрах конвейера, например, что он должен доставлять изменения до продуктивной среды в течение 15 минут. Такой четкий ориентир поможет определить, работает конвейер эффективно или нет, избегая неопределенных формулировок вроде 'как бы работает, но не очень'.
Какие отличия описываются между каталогом для заказчиков и каталогом для пользователей в этой книге?
Книга описывает два различных типа каталогов: Service Catalog (каталог для заказчиков) и Service Request Catalog (каталог для пользователей). Авторы подчеркивают, что это два совершенно разных инструмента, хотя и связанных общей темой предоставления ИТ-услуг. Service Catalog ориентирован на руководителей бизнес-направлений и содержит информацию об услугах, их стоимостях и уровнях сервиса. Service Request Catalog предназначен для конечных пользователей и содержит шаблоны запросов на стандартные услуги, которые пользователь может легко заказать.
Документ "описание процесса" в первую очередь предназначен для менеджера, отвечающего за данный процесс. Этот документ предоставляет ему полную картину процесса, необходимую для его управления и контроля. Также он востребован менеджерами смежных процессов, чтобы понимать взаимодействие с описанным процессом, и для аудиторов, которые используют его для сравнения того, как процесс был задуман, и как он реально функционирует на практике.
Сервисный подход — это метод управления, который необходим прежде всего для решения задач взаимодействия ИТ-службы и заказчиков услуг. Его применение актуально не для всех ИТ-служб, а только в тех случаях, когда между ИТ-службой и заказчиками установлены отношения поставщика и потребителя услуг. Ключевой аспект сервисного подхода — взаимное понимание и приемка со стороны обеих сторон: заказчика и поставщика услуг. Одностороннее применение этого подхода без участия заказчика обычно не приносит ожидаемых результатов и может оказаться бесполезным.
Новые возможности визуализации CMDB позволяют значительно упростить анализ инфраструктурных инцидентов. Теперь можно легко определять, какие конфигурационные единицы (CI) влияют на конкретную услугу, и оценивать последствия отказа определенных CI. Благодаря возможности «раскрывать» связи, аналитики могут детально изучить зависимости внутри ИТ-инфраструктуры, быстро находя проблемные участки и планируя решения.
Принципиальная сложность внутренних сервисных отношений по сравнению с коммерческими заключается в том, что внутри компании часто наблюдается разделение функций заказчика и плательщика, множественность заказчиков для одной услуги и сложные пересекающиеся требования от разных подразделений. В коммерческих сценариях (например, предоставление услуг связи, IaaS, SaaS) отношения обычно более четко структурированы и основаны на рыночных механизмах, где заказчик и плательщик - это один и тот же субъект. Во внутренних корпоративных отношениях же сложность взаимодействия значительно выше, поскольку решения принимаются в рамках единой организации с разными интересами и целями у подразделений, что делает модель Value chain слишком упрощенной для адекватного описания реальных процессов.
Желания (Запад) в модели Compass Model представляют собой менее конкретные, не всегда осознаваемые потребителем, цели и пожелания. Эти пункты не являются критически необходимыми, но существенно повышают удовлетворённость, когда реализуются. Чтобы выявить желания, следует задавать вопросы: "Что клиент хотел бы дополнительно?", "Какие необязательные элементы улучшили бы его опыт?" Например, для такси в командировке желаниями могут быть: прибытие вовремя, вежливый водитель, комфортная езда, приятная музыка и отсутствие навязчивых разговоров. Желания часто определяют дифференциацию сервиса и возможность превосходства над конкурентами.
Наиболее распространенные варианты организации работы мобильных сотрудников включают три основных подхода: работа через электронную почту, использование веб-клиента и мобильных приложений. Каждый из этих методов имеет свои преимущества и ограничения, которые определяют их применимость в конкретных условиях и типах бизнес-процессов.
Модель 'as-a-Service' помогает четко разделить товар и услугу, акцентируя внимание на том, что клиент покупает не просто продукт, а доступ к функциональности с перекладыванием определенных рисков и затрат на поставщика. Например, если рассматривать Chocolate-as-a-Service, клиент получает не просто шоколадку, а регулярную доставку, обеспечение свежести, решение вопросов с доступностью - поставщик берет на себя ответственность за эти аспекты. Аналогично в ИТ: SaaS (Software-as-a-Service) означает, что клиент использует программное обеспечение без необходимости его установки и обслуживания - эти функции берет на себя поставщик. Основная идея в том, что при использовании модели 'as-a-Service' клиент получает конечную ценность без несения полной ответственности за поддержку инфраструктуры или процессов.
Первая линия поддержки может способствовать улучшению общей эффективности многоуровневой системы через грамотную первичную диагностику и отсеивание технических запросов, которые могут быть решены на этом уровне без эскалации; корректное направление инцидентов к соответствующим специалистам второй линии для предотвращения циклического перенаправления; обеспечение четкой и структурированной информации при эскалации, что сокращает время на повторный анализ проблемы; активное мониторинга статуса эскалированных инцидентов и своевременное напоминание ответственным при приближении к SLA; предоставление обратной связи от пользователей внутренним командам для постоянного улучшения процессов. Эффективная первая линия служит фундаментом, на котором строится успешная многоуровневая система поддержки.