В контексте управления уровнем ИТ-услуг процесс SLM (Service Level Management) соответствует циклу PDCA (Plan-Do-Check-Act). Этот процесс ответственен за реализацию цикла PDCA над оперативной деятельностью в рамках жизненного цикла услуг, направленного на постепенное устранение несоответствий между ожиданиями заказчика услуг и реальными показателями предоставляемых услуг. Таким образом, SLM обеспечивает постоянное улучшение качества ИТ-услуг через планомерное выявление и устранение недостатков.

Принцип ITIL 4, наиболее напрямую связанный с концепцией 'Целое больше суммы частей', - это 'Используйте целостный подход' (Think and work holistically), указанный в разделе 4.3.5 руководства ITIL 4. Этот принцип подчеркивает необходимость понимания того, как все части организации работают вместе интегрированным образом для предоставления услуг. Он включает в себя рассмотрение всех четырех аспектов управления ИТ-услугами как взаимосвязанных элементов, которые необходимо координировать совместно, а не работать с ними выборочно. Принцип предполагает, что услуги предоставляются посредством координации этих аспектов, и только такой интегрированный подход позволяет создать ценность, превосходящую сумму отдельных составляющих. Это означает, что любое управление отдельными элементами без учета их взаимодействия с другими приведет к снижению общей эффективности.

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

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

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

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

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

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

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

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