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

Особенность подхода Гартнера к оценке ITSM-решений заключается в том, что он смещает акцент с технических характеристик продуктов на оценку компаний-поставщиков как потенциальных долгосрочных партнеров. Гартнер призывает корпоративных покупателей отвлекаться от деталей реализации, функционала и производительности продукта, сосредотачиваясь на способности поставщика поддерживать стратегическое партнерство. Такой подход имеет смысл для крупных организаций, но критикуется за недостаточное внимание к реальным возможностям ITSM-продуктов.

Низкой эффективности потока в командах разработки (3-10%) способствуют несколько факторов: большое количество задач в системе, нежелание делать сложный выбор между задачами, склонность брать новые, понятные задачи вместо решения уже начатых сложных задач, использование статуса 'отложено' для задач, требующих уточнений или участия отсутствующих сотрудников. Все это приводит к тому, что значительная часть трудозатрат превращается в простои и не добавляет ценности, а время ожидания для отдельных задач достигает 90-97% от общего времени нахождения в системе.

Ценность роли тимлида можно измерить через несколько показателей: снижение количества блокеров и увеличение скорости принятия решений, рост технического долга (должен снижаться при правильной работе тимлида), уровень самоорганизации команды (должен постепенно расти), текучесть кадров (низкая текучесть указывает на хороший уровень мотивации), скорость вхождения новых членов в команду (должна увеличиваться), количество внешних претензий к работе команды (должно снижаться), уровень удовлетворенности заказчика. Однако ключевым показателем является постепенное снижение зависимости команды от действий одного человека, что свидетельствует о правильном подходе тимлида к распределению ответственности.

Автоматизация проверки CMDB включает использование сканеров обнаружения CI (например, ServiceNow Discovery, Lansweeper), интеграцию с системами мониторинга (Zabbix, Nagios) для сравнения реальных показателей с записями CMDB, и настройку триггеров на аномальные изменения (например, массовое обновление атрибутов за короткий срок). Для статических данных применяются скрипты сравнения с источниками доверенных данных (активы в финансовой системе). Ключевой элемент — регулярные сверки через API между CMDB и системами управления изменениями, чтобы отслеживать соответствие внесенных изменений утвержденным запросам.

Правило «расщепления» — это методика разбиения комплексного актива на отдельные учетные единицы для детализации затрат. Например, при постановке рабочей станции на учет по правилам «расщепления» системный блок, монитор и периферийные устройства регистрируются как самостоятельные активы с уникальными инвентарными номерами и сроками амортизации. Это позволяет ИТ-службам вести контроль за состоянием и заменой отдельных компонентов, а финансовым службам — более точно распределять расходы. Реализация требует четкого определения типов активов, подпадающих под такое расщепление.

Управление рисками и управление ограничениями проекта представляют собой разные аспекты проектной деятельности. Риски — это потенциальные события или условия, которые могут повлиять на достижение целей проекта, тогда как ограничения — это жесткие рамки, в которых должен быть выполнен проект (сроки, бюджет, качество, охват). Риски могут стать причиной выхода за установленные ограничения, но сами по себе они не являются ограничениями. Управление рисками направлено на предотвращение или смягчение негативных событий, тогда как управление ограничениями фокусируется на поддержании проекта в заданных рамках и согласовании изменений при необходимости. Эти процессы взаимодействуют, но не должны смешиваться.

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

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

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