Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Российские компании демонстрируют более низкий уровень операционных затрат (55-60%) по сравнению с западными (73% и выше), что связано с меньшей долей аутсорсинга и особенностями инвестиционной активности. Однако в условиях кризиса российские компании сокращают капитальные вложения, что приводит к увеличению доли операционных затрат. Западные компании более активно используют аутсорсинг и автоматизацию, снижая таким образом долю затрат на персонал.
Согласно мини-опросу, проведённому на портале, операционные затраты составляют 67-68% от общего объёма затрат на ИТ. В банках этот показатель достигает 76-79% (по данным за 2015 год), тогда как международная статистика (Computer Economics) указывает на 73%. Затраты на персонал в операционных расходах варьируются от 40-60% в российских компаниях до 30-40% в западных. Эти данные подчёркивают необходимость детального анализа структуры затрат для их оптимизации.
В ITIL подчеркивается важность простоты и практичности решений, потому что слишком сложные решения часто труднее внедрять и поддерживать, что может привести к снижению эффективности и качества предоставления услуг. Однако простота ради простоты не является самоцелью - решение должно быть достаточно простым для понимания и реализации, но в то же время практически полезным и решать поставленные задачи. Баланс между простотой и практичностью помогает организациям избегать излишней бюрократии и сложности в процессах, сохраняя при этом их эффективность и соответствие потребностям организации и ее клиентов. Этот баланс особенно важен при адаптации общих рекомендаций ITIL к специфике конкретной организации.
Интеграция стандартных изменений в каталог поддержки осуществляется следующим образом: - Формализация и документирование: каждое стандартное изменение должно быть сформулировано максимально конкретно, с четким описанием процедуры выполнения, необходимых ресурсов, последовательности действий и ожидаемых результатов. - Присвоение уникального идентификатора: каждому стандартному изменению присваивается уникальный код или название, что позволяет легко идентифицировать и отслеживать его в процессе поддержки. - Классификация по направлениям: стандартные изменения группируются в каталоге по категориям (например, по типам сервисов, системам или направлениям в ИТ-инфраструктуре), что облегчает поиск и выбор подходящей процедуры. - Интеграция с SLA: для стандартных изменений могут быть установлены нормативы SLA, определяющие максимальное время выполнения, условия и критерии успешной реализации. - Связь с управлением запросами: стандартные изменения тесно связаны с процессом управления запросами на обслуживание, особенно те, которые доступны конечным пользователям через службы поддержки. - Обучение персонала: сотрудники поддерживающих служб должны быть обучены процедурам реализации стандартных изменений, что обеспечивает их корректное применение без необходимости анализа и оценки каждый раз. - Периодический аудит и обновление: каталог стандартных изменений должен периодически пересматриваться для исключения устаревших процедур и добавления новых типовых задач. Эта интеграция позволяет значительно ускорить обработку типовых запросов и освободить ресурсы для работы с более сложными, нестандартными изменениями.
Сложность построения ролевой модели значительно возрастает при увеличении числа управляемых информационных систем в проекте. Это связано с необходимостью учета всех прав и привилегий в различных системах, а также с учетом того, что различные сотрудники могут иметь различные наборы прав даже при одинаковой должности. Создание полной и актуальной ролевой модели для множества систем с нуля может занять месяцы или даже годы и к моменту завершения разработки модель может уже устареть.
Конфликт интересов в контексте выполнения работ возникает, когда исполнение обязанностей различного рода приводит к ситуации, где личные или профессиональные интересы могут повлиять на объективное выполнение задач. Это происходит, когда одна и та же персона выполняет функции, которые требуют противоположных подходов или решений, например, когда сотрудник выступает одновременно в роли исполнителя и проверяющего, что создает противоречивые обязательства и может негативно сказаться на качестве работы.
Основной функцией управления событиями в системах ИТ-управления является способность обнаруживать события, толковать их и определять подходящий способ реагирования. Это включает в себя не только фиксацию происходящего, но и интерпретацию полученных данных для принятия правильных решений. Система управления событиями должна обеспечивать понимание, кому предназначена информация, какие требования предъявляются к данным, какая модель данных используется, как происходит сбор данных и как оценивается их полезность.
Руководитель отдела сопровождения прикладных систем рекомендуется в качестве менеджера процесса управления инцидентами, так как именно на его отдел приходится основной поток обращений, связанных с нарушением бизнес-операций. Этот процесс требует эффективного взаимодействия с разработчиками ПО, внешними поставщиками, отделом ИТ-инфраструктуры и первой линией поддержки. Руководитель отдела сопровождения лучше понимает специфику прикладного ПО и может организовать сквозной процесс, а не изолированную функцию поддержки. Благодаря этому повышается ценность процесса управления инцидентами и снижаются операционные риски, связанные с нарушением работоспособности прикладного ПО.
Управление проблемами состоит из двух основных компонентов: Реактивная составляющая: - Фокусируется на решении уже произошедших инцидентов - Начинается после возникновения инцидента и его регистрации в системе - Цель - определить корневую причину инцидента и устранить ее, чтобы предотвратить повторение - Тесно связана с процессом управления инцидентами - Использует данные об инцидентах для анализа и выявления проблем Проактивная составляющая: - Направлена на выявление и решение проблем до того, как они вызовут инциденты - Включает анализ трендов, статистики инцидентов, мониторинг системы и поиск потенциальных узких мест - Включает управление рисками: идентификацию событий, оценку вероятности и влияния, контроль реестра - Связана с практиками постоянного совершенствования - Позволяет предвосхитить и устранить проблемы, минимизируя их влияние на бизнес Оптимально развитая система управления проблемами включает обе составляющие, где проактивная работа дополняет и усиливает реактивную, снижая общее количество инцидентов и улучшая качество предоставляемых услуг.
Неправильная классификация обращений может привести к искажению отчетности по ИТ-услугам, неправильному расчету сроков выполнения по соглашениям об уровне обслуживания (SLA), некорректному определению ответственных сотрудников и, как следствие, к принятию неверных управленческих решений по улучшению процессов. Все это ухудшает взаимодействие с бизнес-подразделениями и снижает эффективность всего отдела ИТ, что в конечном счете влияет на качество предоставления услуг и удовлетворенность пользователей.