Проблемы при расчете Flow Efficiency в ИТ-процессах включают несколько аспектов: 1) Сложность определения Time in Process, так как необходимо учитывать только рабочее время, а не календарное, особенно когда члены команды работают по разным графикам или в разных часовых поясах. 2) Невозможность точно измерить Touch Time из-за частых переключений между задачами, перерывов и других видов деятельности во время рабочего дня. 3) Проблема учета времени при совместной работе нескольких исполнителей над одной задачей. 4) Неточность расчета при использовании стандартных инструментов вроде Jira, которые фиксируют изменения статусов задач, но не отражают детальное время непосредственной работы.

Google провела исследование Project Oxygen с целью научно обосновать влияние менеджеров на эффективность работы сотрудников и всей организации. Первоначально руководство компании стремилось доказать, что менеджеры не имеют существенного влияния на результаты, что могло бы подтвердить целесообразность радикального сокращения управленческого звена. Однако исследования показали обратное: от качества работы руководителей напрямую зависят как индивидуальные достижения сотрудников, так и общий успех организации. Это открытие привело к переосмыслению роли менеджеров в компании и к созданию системы подготовки руководителей на основе выявленных ключевых компетенций.

Понятия сервиса и менеджмента в профессии сервис-менеджера тесно связаны и дополняют друг друга. Сервисная часть отражает искреннее желание помочь заказчику, построить доверительные отношения и поддерживать его в решении задач. Менеджмент же подразумевает возможность организации и контроля процессов, обеспечения взятых обязательств и влияния на системы и ресурсы. Без сочетания этих двух элементов роль сервис-менеджера становится урезанной: либо формальной, либо ограниченной узкими рамками компетенции.

В ITIL 4 назначение практики управления инцидентами формулируется следующим образом: «Минимизировать негативное влияние инцидентов, восстанавливая нормальную работу услуг как можно быстрее». Основной недостаток этой формулировки заключается в том, что она акцентирует внимание преимущественно на скорости восстановления услуги, тогда как в действительности удовлетворённость пользователей зависит от множества других факторов, таких как качество коммуникаций, количество контактов с поддержкой и окончательность решения. Хотя в более подробном описании практики в ITIL 4 упоминается важность удовлетворённости пользователей, в самой формулировке назначения эта цель не отражена явно, что может приводить к тому, что организации сосредотачиваются только на скорости решения инцидентов, упуская из виду другие значимые аспекты.

Среди примерно 70 участников семинара процесс управления изменениями оказался внедренным и работающим лишь у 10-12 человек. Это свидетельствует о том, что данная область в ИТ-управлении находится на этапе внедрения и не является стандартной практикой для большинства организаций, участвующих в мероприятии.

Для нормирования задач сопровождения CMDB можно использовать несколько методов. Первый метод - ведение полного или выборочного учета трудозатрат («списание часов»), что позволяет накапливать статистику и на ее основе устанавливать нормативы для аналогичных задач в будущем. Второй метод - консолидация внешней статистики с портала REALITSM.RU, где можно найти данные и наработки других организаций по оценке трудозатрат. Третий метод - детальная разбивка задач по группам конфигурационных единиц (ИТ-системы, бизнес-приложения, технологические элементы бизнес-приложений, инфраструктура) и ролям специалистов с учетом различной стоимости рабочего времени и требований к компетенциям. Четвертый метод - разработка внутренних стандартов и нормативов для каждой из задач сопровождения CMDB (первичная регистрация, обновление статусов, аудит, инвентаризация и т.д.) на основе оценки их сложности и требуемых ресурсов. Пятый метод - регулярный пересмотр и корректировка нормативов на основе анализа фактических трудозатрат и изменений в процессах работы с CMDB.

Согласно первому принципу DevOps, использование коротких циклов обратной связи предоставляет несколько ключевых преимуществ. Во-первых, это позволяет быстрее получать информацию о том, насколько продукт или услуга соответствуют ожиданиям и потребностям заказчиков, что способствует более оперативной корректировке направления разработки. Во-вторых, короткие циклы обратной связи уменьшают риск серьёзных отклонений от целей и потребностей клиентов, так как любые несоответствия выявляются на ранних этапах. В-третьих, это повышает вовлечённость заказчиков в процесс разработки, создавая культуру сотрудничества и диалога. Наконец, короткие циклы обратной связи поддерживают постоянные инновации, позволяя командам тестировать новые идеи в реальных условиях и быстро отсеивать неперспективные направления, сохраняя при этом фокус на создании ценности для конечного пользователя.

В Change proposal должно быть высокоуровневое описание услуги с указанием бизнес-выгод, требований к функциональности и гарантиям (доступность, мощность, безопасность), подробный бизнес-кейс с экономической выгодой, рисками, альтернативами решения и графиком внедрения, а не просто фиксированным дедлайном. Это позволяет принимать обоснованные решения на стратегическом уровне.

DAC-модель менее эффективна для крупных систем из-за следующих причин: 1) Масштабируемость — в DAC разрешения настраиваются для каждого пользователя и объекта вручную (через таблицы доступа), что приводит к экспоненциальному росту сложности при увеличении пользователей и ресурсов. Например, для 100 пользователей и 1000 объектов потребуется управлять 100 000 записей. 2) Высокий риск ошибок — при изменении прав для группы сотрудников администратор должен править каждую запись отдельно, что увеличивает вероятность пропуска. 3) Несогласованность — отсутствие структурирования по бизнес-функциям делает модель неинтуитивной. В RBAC те же права группируются в роли (например, 'Бухгалтер'), что сокращает необходимость ручных настроек в сотни раз.

Некорректное определение времени решения инцидента в SLA может привести к постоянным спорам между ИТ-службой и клиентами, искажению статистики по выполнению обязательств и несправедливой оценке работы специалистов. Это может вызвать снижение доверия к ИТ-службе, увеличение количества претензий и штрафных санкций по договору. Кроме того, неопределенность в критериях может негативно сказаться на мотивации сотрудников ИТ-службы, так как они не смогут четко понимать, какие результаты от них ожидают и как их оценивают.