Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Проблемы при расчете Flow Efficiency в ИТ-процессах включают несколько аспектов: 1) Сложность определения Time in Process, так как необходимо учитывать только рабочее время, а не календарное, особенно когда члены команды работают по разным графикам или в разных часовых поясах. 2) Невозможность точно измерить Touch Time из-за частых переключений между задачами, перерывов и других видов деятельности во время рабочего дня. 3) Проблема учета времени при совместной работе нескольких исполнителей над одной задачей. 4) Неточность расчета при использовании стандартных инструментов вроде Jira, которые фиксируют изменения статусов задач, но не отражают детальное время непосредственной работы.
Google провела исследование Project Oxygen с целью научно обосновать влияние менеджеров на эффективность работы сотрудников и всей организации. Первоначально руководство компании стремилось доказать, что менеджеры не имеют существенного влияния на результаты, что могло бы подтвердить целесообразность радикального сокращения управленческого звена. Однако исследования показали обратное: от качества работы руководителей напрямую зависят как индивидуальные достижения сотрудников, так и общий успех организации. Это открытие привело к переосмыслению роли менеджеров в компании и к созданию системы подготовки руководителей на основе выявленных ключевых компетенций.
Понятия сервиса и менеджмента в профессии сервис-менеджера тесно связаны и дополняют друг друга. Сервисная часть отражает искреннее желание помочь заказчику, построить доверительные отношения и поддерживать его в решении задач. Менеджмент же подразумевает возможность организации и контроля процессов, обеспечения взятых обязательств и влияния на системы и ресурсы. Без сочетания этих двух элементов роль сервис-менеджера становится урезанной: либо формальной, либо ограниченной узкими рамками компетенции.
В ITIL 4 назначение практики управления инцидентами формулируется следующим образом: «Минимизировать негативное влияние инцидентов, восстанавливая нормальную работу услуг как можно быстрее». Основной недостаток этой формулировки заключается в том, что она акцентирует внимание преимущественно на скорости восстановления услуги, тогда как в действительности удовлетворённость пользователей зависит от множества других факторов, таких как качество коммуникаций, количество контактов с поддержкой и окончательность решения. Хотя в более подробном описании практики в ITIL 4 упоминается важность удовлетворённости пользователей, в самой формулировке назначения эта цель не отражена явно, что может приводить к тому, что организации сосредотачиваются только на скорости решения инцидентов, упуская из виду другие значимые аспекты.
Постепенное внедрение процесса управления изменениями позволяет избежать сопротивления сотрудников, дает время на освоение новых процедур и формирование культуры работы с процессом. Оно также снижает риски связанные с внезапным изменением рабочих привычек и дает возможность корректировать процесс на ранних стадиях.
В SWOT-анализе выделяются две группы причин возникновения рисков: внешние и внутренние. Внешние причины относятся к факторам окружающей среды, таким как рынок или организационное окружение, и относятся к квадранту «Угрозы». Внутренние причины связаны с собственными характеристиками организации, такими как структура управления или внутренние процессы, и относятся к квадранту «Слабые стороны». Разделение этих причин позволяет более точно определить источники рисков и выбрать стратегии их нейтрализации.
Среди примерно 70 участников семинара процесс управления изменениями оказался внедренным и работающим лишь у 10-12 человек. Это свидетельствует о том, что данная область в ИТ-управлении находится на этапе внедрения и не является стандартной практикой для большинства организаций, участвующих в мероприятии.
Для нормирования задач сопровождения CMDB можно использовать несколько методов. Первый метод - ведение полного или выборочного учета трудозатрат («списание часов»), что позволяет накапливать статистику и на ее основе устанавливать нормативы для аналогичных задач в будущем. Второй метод - консолидация внешней статистики с портала REALITSM.RU, где можно найти данные и наработки других организаций по оценке трудозатрат. Третий метод - детальная разбивка задач по группам конфигурационных единиц (ИТ-системы, бизнес-приложения, технологические элементы бизнес-приложений, инфраструктура) и ролям специалистов с учетом различной стоимости рабочего времени и требований к компетенциям. Четвертый метод - разработка внутренних стандартов и нормативов для каждой из задач сопровождения CMDB (первичная регистрация, обновление статусов, аудит, инвентаризация и т.д.) на основе оценки их сложности и требуемых ресурсов. Пятый метод - регулярный пересмотр и корректировка нормативов на основе анализа фактических трудозатрат и изменений в процессах работы с CMDB.
В Change proposal должно быть высокоуровневое описание услуги с указанием бизнес-выгод, требований к функциональности и гарантиям (доступность, мощность, безопасность), подробный бизнес-кейс с экономической выгодой, рисками, альтернативами решения и графиком внедрения, а не просто фиксированным дедлайном. Это позволяет принимать обоснованные решения на стратегическом уровне.
Зрелость организации в управлении проблемами определяется способностью не только выявлять и устранять технические неполадки, но и успешно управлять организационными аспектами, такими как исполнение, взаимодействие, принятие решений и контроль. Это проявляется в том, что компания системно работает над развитием своих процессов, включая оргвопросы в охват управления проблемами, и не ограничивается реагированием на технические сбои, а предотвращает инциденты еще до их возникновения.