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

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

25
авторов

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

100%
оригинальный контент
Преодоление шаблона поведения, при котором сотрудники не уточняют требования у заказчиков, возможно через несколько направлений. Важно внедрять регулярные практические упражнения, имитирующие реальные ситуации взаимодействия с клиентом, где явно недостаёт информации, и участники тренируются задавать правильные вопросы. Также необходимо создавать культуру, где уточнение требований считается профессиональной нормой, а не признаком непрофессионализма. Можно использовать обратную связь от коллег и заказчиков для показа последствий неверного понимания задачи. В долгосрочной перспективе важно сочетать тренинги по сервисному подходу с правильным подбором персонала, обращая внимание на коммуникативные качества кандидатов.
В контексте соглашений об уровне услуг (SLA) владелец услуги участвует в обсуждении SLA/OLA применительно к услуге, находящейся в его зоне ответственности. Он обеспечивает соответствие уровня предоставления и поддержки услуги согласованным параметрам SLA. Владелец услуги также транслирует требования бизнеса в понятные ИТ-задачи, обеспечивает прозрачные коммуникации с заказчиком по запросам и инцидентам в контексте конкретной услуги и представляет услугу в рамках всей организации, включая участие в обсуждениях на CAB (Change Advisory Board).
Совместная работа команд при управлении значительным инцидентом должна быть организована через четко определенную структуру координации, включающую назначение ответственного лица за управление инцидентом. Должен быть создан оперативный штаб или комната для координации действий, где представители всех задействованных подразделений (ИТ, административный отдел, информационная безопасность, связь) могут оперативно обмениваться информацией. Должны быть определены роли и полномочия каждого участника процесса, установлены каналы коммуникации и протоколы взаимодействия. Важно организовать централизованное управление обращениями через сервис-деск и распределение задач между командами с постоянным обновлением статуса инцидента. Методы координации должны быть отработаны заранее в рамках специальной процедуры.
Финансовые показатели, зависящие от доступности ИТ-систем, включают в себя убытки от простоев (потерянная выручка, штрафы за невыполнение SLA), затраты на восстановление услуг, стоимость избыточного резервирования оборудования и потери репутации. Высокая доступность снижает риски простоев, что напрямую влияет на стабильность доходов и удовлетворенность клиентов, особенно в критически важных для бизнеса сценариях.
"Fit for use" - это термин, который описывает характеристику Warranty (Гарантия) услуги. Он означает, насколько услуга находится в том состоянии, чтобы пользователь мог ею пользоваться без проблем. "Fit for use" определяется четырьмя компонентами: доступность (может ли пользователь получить услугу, когда это необходимо), мощность (достаточно ли ресурсов для удовлетворения запросов), безопасность (защищена ли услуга от несанкционированного доступа) и непрерывность (насколько услуга устойчива к перебоям). Например, если свет в комнате мигает, то при его высокой полезности (способности помочь читать в темноте) он имеет низкую пригодность к использованию из-за нестабильности работы.
Талантливые руководители в деловых играх получают лучшие результаты, потому что они не стремятся выполнять работу сами, а стараются организовывать процесс. Они объясняют команде не только как, но и зачем что-то нужно сделать, показывают разницу между хорошим и плохим результатом, определяют приоритеты устранения недостатков. Они добиваются, чтобы участники сами определили, как устроить работу и взаимодействие, какие организационные изменения реализовать. Настоящие руководители выделяют направления ответственности, назначают конкретных ответственных, определяют приоритеты на короткую перспективу и продолжают смотреть на общую картину, не погружаясь полностью в детали.
Для иллюстрации определения услуги в ITIL используется пример центрального горячего водоснабжения, знакомый большинству городских жителей. Центральное водоснабжение представляет собой услугу, которая предоставляет потребителям горячую воду нужной температуры и чистоты в требуемом количестве и в требуемое время. Эта услуга позволяет пользователям стирать белье у себя дома, не задумываясь о внутренних процессах, таких как очистка воды, поддержание трубопроводов или управление котельными. Таким образом, клиент получает конечный результат (чистую одежду) без необходимости взять на себя затраты и риски, связанные с управлением всеми этапами процесса.
Потребитель услуг рассматривает два типа рисков: риски, устраняемые услугой (часть ценностного предложения), которые включают возможные негативные события, от которых услуга защищает потребителя, например, сбой серверного оборудования или нехватку персонала; и риски, налагаемые на потребителя услугой (риски потребления услуги), которые возникают при использовании услуги, например, прекращение деятельности поставщика услуг или нарушение им требований безопасности.
Ответственность за успешность изменений централизована в практике управления изменениями, даже если сами изменения выполняются в рамках других процессов, таких как управление запросами на обслуживание или управление инцидентами. Практика управления изменениями формирует стандартные модели, которые определяют правила и процедуры для безопасного выполнения изменений в других практиках. В свою очередь, другие практики обязаны следовать этим моделям и стандартам. Таким образом, даже когда работа по изменению выполняется в рамках узкого процесса, ответственность за его успешность и безопасность остается с практикой управления изменениями.
Ключевые переменные, влияющие на баланс между Agile (гибкостью) и стабильностью в ИТ: Release rate (частота внедрений) и Release size (средний размер внедрения). Чем выше частота внедрений (Release rate), тем меньшими порциями можно внедрять изменения (меньше Release size), и наоборот. Частые внедрения помогают сокращать размер очереди изменений (Backlog Size), уменьшают риски (Change Risk) и способствуют накоплению опыта. Большой размер релиза приводит к повышенным рискам, поскольку сложнее планировать и контролировать изменения. Также важны Process Time (время работы над изменением), Queue Time (время ожидания в очереди), Change capability (способность ИТ-организации проводить изменения) и Change Control Level (уровень контроля изменений), которые определяют эффективность и качество процесса внедрения изменений в систему.