Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Одной из распространённых ошибок при внедрении системы управления конфигурациями является обращение самой CMDB (Configuration Management Database) в самоцель. Организации часто сосредотачиваются на создании и наполнении базы данных конфигураций, забывая о том, что её основное назначение – поддержка других процессов ИТ-управления. В результате CMS начинает работать как бы сама на себя, без чётко определённых потребителей информации. Такой подход приводит к избыточному сбору данных, которые никем не используются, и к неэффективному использованию ресурсов. Правильная практика предполагает, что построение CMS должно начинаться с определения потребностей бизнес-процессов и конкретных задач, которые эта система должна решать.
Этап согласования необходим для снижения рисков выполнения несанкционированных операций, например, предоставления доступа не к тем ресурсам или не тем пользователям. На этом этапе заявка проходит через несколько уровней утверждения, которые могут включать согласование со стороны непосредственного руководителя пользователя, ответственного за запрашиваемый ресурс, и службы безопасности. В случае если в заявке запрошено несколько ресурсов или работ, только согласованные элементы переходят на этап реализации, что позволяет минимизировать потенциальные ошибки и обеспечивает более строгий контроль над процессом.
Парадигма ITSM охватывает все этапы жизненного цикла информационных систем, создавая единый подход к управлению на каждом из них. От этапа планирования и разработки до внедрения, эксплуатации и вывода из эксплуатации - парадигма определяет соответствующие процессы, методики и стандарты, которые обеспечивают непрерывность обслуживания, минимизацию рисков и согласованность действий. Это означает, что жизненный цикл ИТ-систем рассматривается не как последовательность разрозненных этапов, а как единый процесс, управляемый через призму сервисно-ориентированного подхода.
Регулярные проверки предотвращают накопление избыточных или устаревших прав, которые возникают при изменении должностей сотрудников, реорганизации подразделений или увольнении работников. Например, сотрудник, переведённый на новую должность, может сохранять доступы к системам, необходимым для предыдущей роли, что нарушает принцип минимальных привилегий. Своевременный аудит позволяет выявлять подобные случаи и минимизировать риски утечек данных или внутренних злоупотреблений.
Попытки внедрить единую методологию управления ИТ-процессами обычно заканчиваются неудачно в плане реального повышения эффективности ИТ-отдела. Несмотря на то, что формальные результаты внедрения (документы, установленные системы автоматизации, приказы и распоряжения) могут быть достигнуты, это не приводит к изменению практики работы ИТ-отдела, повышению его эффективности или улучшению качества предоставляемых услуг. Часто возникает ситуация, когда документация создана, но не используется, а сотрудники продолжают работать старыми методами.
Да, проактивное управление проблемами предполагает выявление и устранение ошибок в инфраструктуре до возникновения инцидентов. Например, если известно о потенциальной уязвимости компонента системы, можно заранее внести исправления, не дожидаясь сбоя. Это снижает риски крупных простоев и улучшает стабильность ИТ-услуг. Такой подход особенно важен для критически важных систем, где даже один инцидент может привести к значительным убыткам.
Для минимизации искажения метрик важно: выбирать такие показатели, на которые сотрудник не может напрямую влиять; комбинировать количественные и качественные данные; использовать несколько взаимодополняющих метрик, чтобы получить целостную картину; и проводить регулярный аудит и анализ отклонений. Например, если основная метрика — доля закрытых задач, стоит также учитывать отзывы клиентов и количество повторных обращений по той же проблеме.
SLA 'AS IS' - это соглашение об уровне обслуживания, которое фиксирует текущий уровень предоставления ИТ-сервисов на основе существующей практики и видения ИТ-подразделения о том, как должны предоставляться сервисы. Формируется оно на этапе старта процесса управления сервисами (SLM), без необходимости предварительного согласования с каждым бизнес-заказчиком. SLA 'AS IS' вводится в действие как неотъемлемая часть запускаемого процесса управления сервисами.
Проведение оценки действий по обработке major-инцидента после его устранения важно для идентификации успешных практик и выявления проблемных зон в процессе реагирования. Это позволяет оптимизировать процедуры и документацию, повысить профессиональный уровень персонала и подготовиться к возможным будущим инцидентам. Оценка также необходима для выполнения обязательств перед заказчиками и соблюдения SLA, а также может быть использована как материал для обучения новых сотрудников и улучшения общей зрелости ИТ-процессов организации.
Создание MVP (минимально жизнеспособного продукта) делает роль руководителя проекта временной, потому что после появления первых рабочих версий продукта задача смещается с однократного выполнения проекта к постоянному развитию продукта. Вместо следования изначальному плану и завершения проекта по фиксированным критериям теперь требуется непрерывное улучшение продукта на основе обратной связи, изменение приоритетов и адаптация к рынку. Этот процесс лучше реализуется через управление продуктом, где ответственность за результат и приоритизацию несет владелец продукта, а команда занимается итеративной разработкой. Таким образом, как только достигается MVP, необходимо переходить с проектной модели к продуктовой, делая роль традиционного руководителя проекта неактуальной.