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

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

Time in Process — это общее время, в течение которого задача находилась в потоке, от начала до конца обработки (также называемое Lead Time). Формально он рассчитывается как разница между моментом завершения работы (Done) и моментом начала работы (Start). Однако важно учитывать, что это не просто календарное время, так как в большинстве ИТ-процессов работа ведется только в рабочее время, а не круглосуточно. Правильный расчет предполагает учет именно рабочего времени, а не общего календарного, чтобы избежать искажений результата (например, задача, выполненная за 24 рабочих часа в течение трех календарных дней, будет иметь неадекватно низкую эффективность при учете полных суток).

В подписи делового электронного письма должны присутствовать: полное имя и фамилия отправителя, его должность (например, «руководитель проекта N»), контактный телефон для оперативной связи при необходимости уточнения деталей. Полная подпись важна потому, что она указывает на позицию отправителя в компании, его полномочия и зону ответственности. Если подпись отсутствует или неинформативна (например, «Клара К.»), это может вызвать путаницу и потратить время на выяснение личности отправителя, сводя на нет все предыдущие усилия по составлению качественного письма. Многие компании автоматизируют создание стандартных полных и кратких подписей через настройки почтового клиента.

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

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

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

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

Метрика естественным образом масштабируется: если представить ситуацию, когда группа поддержки представляет собой весь персонал поставщика услуги (то есть единственная группа), то время обработки группой (ti) становится равным общему времени обработки инцидента (Ti). В этом случае формула упрощается до вида: Кгруппы = (1/N) * Σ(1-vi), то есть представляет собой привычную метрику «доля инцидентов, решённых в срок». Таким образом, метрика применима как к отдельным группам, так и к оценке эффективности всего процесса управления инцидентами в целом.

"Технические услуги для технических услуг" — это базовые инфраструктурные компоненты и услуги, которые обеспечивают работоспособность ИТ-систем (технических услуг). Примерами являются поддержка сетей и каналов передачи данных, систем управления базами данных (СУБД), систем хранения данных (СХД). Эти услуги являются фундаментальными и повторяются для поддержки различных ИТ-систем в организации.