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

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

25
авторов

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

100%
оригинальный контент
Сдвиг парадигмы означает глубокое изменение управленческих принципов и организационной культуры, а не простое внедрение новых инструментов. Например, переход от управления по срокам к управлению по потоку требует пересмотра ролей, метрик и подходов к принятию решений. Это затрагивает основы взаимодействия бизнеса и ИТ, а также меняет восприятие ответственности внутри команд.
Определение услуги в ITIL тесно связано с управлением затратами и рисками, поскольку услуга формулируется так, чтобы клиент получал желаемые результаты, не беря на себя ответственность за специфические затраты и риски. Это означает, что поставщик услуги берет на себя все издержки и риски, связанные с процессом предоставления услуги, и только за их управление может запрашивать оплату от клиента. Например, в случае центрального водоснабжения поставщик управляет всеми затратами, такими как обслуживание очистных сооружений и ремонтные работы, а также несет риски, такие как аварийные отключения или загрязнение воды. Это позволяет клиенту избежать связанных с этим сложностей, при этом гарантируя определенный уровень качества услуги.
При формировании SLA с различными графиками работы групп рекомендуется сегментировать типы обращений по группам, которые их обрабатывают. Вместо попытки определить пересечение всех графиков (которое может быть очень узким или даже пустым в случае с разными часовыми поясами), можно разделить виды обращений: например, предоставление прав доступа обрабатывается одной группой по определенному графику, а решение проблем на рабочем месте пользователя – местной командой. Для каждого вида обращений тогда можно установить собственный календарь обработки. Также может потребоваться изменение графиков работы под необходимые бизнес-требования: введение дежурных служб, обеспечение удаленной поддержки или экстренной помощи.
При выборе между аутстаффингом и прямым наймом важно учитывать длительность задачи, уровень вовлеченности сотрудника в процессы компании и общую стоимость владения. Для краткосрочных проектов выгоднее аутстаффинг, так как он сокращает административные затраты. Для постоянной работы предпочтителен прямой найм, особенно в регионах с низким уровнем заработных плат, так как это дешевле в долгосрочной перспективе. Также необходимо оценивать потребность в контроле над процессами и знании внутренних стандартов компании.
Аутсорсинг менее эффективен, когда задачи носят постоянный характер и требуют глубокого понимания внутренних процессов компании. В таких случаях прямой набор сотрудников обходится дешевле, так как стоимость аутсорсинга включает дополнительные наценки и не компенсирует затраты на управление проектом. Кроме того, при аутсорсинге теряется контроль над качеством и сроками выполнения работ, что особенно критично для ключевых бизнес-функций.
Правильная настройка целевых показателей разрешения инцидентов позволяет повысить оперативность реагирования на проблемы, эффективнее распределять ресурсы ИТ-служб и минимизировать влияние сбоев на бизнес-процессы. Это способствует улучшению качества ИТ-услуг, повышению удовлетворенности клиентов и сотрудников, а также снижению общей нагрузки на персонал за счет четкой и предсказуемой системы приоритизации и планирования. В итоге создается более устойчивая и гибкая система управления инцидентами, которая адаптируется под реальные потребности организации.
В условиях динамично меняющейся среды RBAC может столкнуться с несколькими проблемами. Во-первых, частые изменения бизнес-процессов и ИТ-систем требуют постоянного перепроектирования ролей, что увеличивает нагрузку на аналитиков. Во-вторых, высокая скорость изменений может сделать ролевую модель устаревающей, что снижает её эффективность. В-третьих, может возникнуть необходимость в увеличении штата сотрудников для поддержки модели, что не всегда возможно из-за бюджетных ограничений. Однако полный отказ от RBAC обычно не рекомендуется, так как это привело бы к потере преимуществ в прозрачности, масштабируемости и администрировании системы управления доступом.
Точность «доски аварий» повышается за счёт постепенного развития CMDB, включения в неё критически важных связей, а не всех возможных, и настройки правил для фильтрации значимых событий. Также помогает добавление контекста к уведомлениям (например, пометка «сервер резервный» или «влияние на услуги через 1 час»). Регулярный аудит данных и обучение персонала на основе реальных кейсов снижают риски ошибок.
При управлении финансами ИТ-услуг важно оценивать не только стоимость предоставления технических компонентов (выходов), но и финансовую выгоду, которую получает бизнес от использования услуги (результат). Например, инвестиции в ускорение системы электронной почты могут быть оправданы, если это сокращает время принятия решений на 20%, что напрямую увеличивает прибыль. Это позволяет обоснованно планировать бюджет, выделяя средства на те проекты, которые дают максимальный возврат инвестиций, а не только на технически привлекательные решения.
После этапа, когда работа считается завершенной после подтверждения тестировщиком, следующим этапом в эволюции Definition of Done является Agile-подход, при котором работа считается завершенной после того, как владелец продукта принял результат разработки. В соответствии с подходами, такими как SAFe, владелец продукта является единственным членом команды, который может принимать истории как выполненные, что включает проверку соответствия критериям Definition of Done. Для больших организаций этот процесс усложняется дополнительными уровнями приемки: на уровне команды, системы, решения и релиза.