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

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

25
авторов

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

100%
оригинальный контент
Процесс EDM01 «Обеспечение создания и обновления подхода к руководству» отвечает за управление системой руководства ИТ. Его задача заключается в обеспечении создания и поддержания практики руководства ИТ, то есть он обеспечивает формирование и обновление подхода к руководству. Объектом этого процесса выступают сами процессы руководства (EDM02–EDM04). Практики процесса EDM01 включают оценку текущего состояния системы руководства, определение направления её развития и мониторинг эффективности системы руководства.
Двухскоростное ИТ — это модель, при которой одни команды сосредоточены на быстрой разработке и внедрении изменений в ключевые продукты (цифровые инициативы), а другие обеспечивают стабильность и бесперебойную работу вспомогательных систем (традиционные ИТ-процессы). Эта модель возникает в компаниях, которые не изначально цифровые: сначала формируется эксплуатационное подразделение для поддержки унаследованных систем, а затем ключевые продукты выделяются в отдельные команды, работающие по гибким методологиям. Несбалансированность скоростей этих двух уровней приводит к конфликтам и снижению эффективности.
Удовлетворенность пользователей важна в системе оценки работы ИТ-подразделения, потому что ИТ существует для обслуживания бизнеса и предоставления качественных услуг конечным пользователям. Хотя некоторые считают опросы удовлетворенности субъективными и ненадежными (мнение может зависеть от настроения пользователя), на практике это один из самых важных факторов оценки эффективности ИТ. Если пользователи недовольны, это напрямую влияет на продуктивность бизнеса. Большинство ИТ-процессов направлены на обеспечение стабильности, скорости, качества и удобства предоставления услуг конечным пользователям. Поэтому игнорирование этого аспекта при построении системы KPI может привести к измерению технических показателей, которые не имеют реальной ценности для бизнеса. Оценивать работу ИТ только через объективные технические метрики (например, данные из Service Desk) без учета мнения пользователей — значит упускать ключевой аспект успешности ИТ-услуг, который в конечном счете определяет их ценность для организации.
Границы между командами, разрабатывающими и поддерживающими клиентское приложение и систему управления производством, значительно затруднили коммуникацию и синхронизацию планов. Планы развития приложения не были согласованы с возможностями команды развития производственной системы. Команда, отвечающая за клиентское приложение, не оценила правильно трудности, с которыми сталкивается команда по поддержке производственной системы, как внешние негативные факторы. Различия в скорости работы, принципах организации и разделении развития и сопровождения приложений создали атмосферу «мы и они», что дополнительно усугубило ситуацию, приведя к мультипликативному эффекту проблем, а не их аддитивному сложению.
Рынок сформировался таким образом, что поставщики услуг предпочитают снимать с себя ответственность за ключевые параметры сервисов. Телеком-провайдеры ограничивают ответственность короткими сроками простоя (часы), устанавливая незначительные штрафы, несмотря на критическую важность связи для клиентов. Химчистки аналогичным образом исключают ответственность за фурнитуру и пятна, хотя именно эти параметры являются основными причинами обращения клиентов. Это происходит потому, что конкуренция строится не на качестве гарантий, а на других факторах (цена, скорость, дополнительные услуги). Рыночные игроки не видят выгоды в изменении условий, так как клиенты продолжают пользоваться услугами даже при отсутствии гарантий, что снижает стимулы для внедрения более жестких обязательств.
Для дополнения ролевой модели управления доступом (RBAC) рекомендуется использовать управление доступом на основании запросов на предоставление прав доступа. Эта стратегия подразумевает, что пользователь самостоятельно запрашивает дополнительные права при возникновении потребности. Запрос проходит проверку, согласование и, при одобрении, приводит к выдаче прав. Такой подход можно автоматизировать через портал самообслуживания. Также полезно интегрировать ролевую модель с кадровой системой и обрабатывать изменения, связанные с кадровыми событиями, автоматически. Кроме того, регулярное проведение аудитов прав доступа помогает своевременно отзывать неиспользуемые права и поддерживать безопасность системы.
При выполнении работ с участием нескольких групп ИТ-специалистов часто возникают проблемы, связанные с отсутствием четкого разграничения ответственности. Например, в поддержке обращение может быть просрочено, но каждая группа утверждает, что выполнила свою часть работы вовремя и качественно. В управлении конфигурациями может возникать ситуация, когда сервер установлен, но связи с прикладным ПО в CMDB не настроены, так как прикладные специалисты и инфраструктурщики ссылаются друг на друга. В управлении изменениями отдельные этапы изменения (подготовка стойки, сервера, сетевого сегмента) могут быть выполнены идеально, но конечный результат не будет достигнут из-за отсутствия синхронизации между группами.
Традиционно временем решения инцидента в SLA считается период от регистрации обращения до завершения работ специалистом. Это включает в себя все этапы обработки инцидента, начиная с момента его фиксации в системе и до полного устранения проблемы и закрытия обращения.
В открытые записи инцидентов не должны попадать такие типы информации, как параметры настройки ИТ-систем и оборудования, пароли пользователей и системных учетных записей, лицензионные ключи к программному обеспечению. Также сам факт регистрации инцидента может быть конфиденциальным, особенно если он связан с уязвимостью в системе безопасности. Наблюдения показывают, что подобная информация часто неоправданно становится доступной широкому кругу сотрудников, что создает дополнительные риски для безопасности организации.
Достоверность информации в CMDB достигается несколькими способами: ограничением круга лиц, имеющих возможность обновления данных; контролем соблюдения установленных правил учета; регулярным пересмотром структуры и правил учета; выявлением и устранением расхождений как периодическими аудитами, так и в процессе повседневной работы. Ограничение числа операторов упрощает их обучение и контроль качества, что критически важно для поддержания высокой достоверности информации, необходимой для принятия решений.