Книга рекомендует даже в ситуациях, когда ИТ-подразделение находится внутри компании, рассчитывать стоимость услуг и управлять ИТ-подразделением почти как бизнесом (more like a business), даже если фактических взаиморасчетов с бизнес-подразделениями нет. Это позволяет ИТ-руководству более четко обосновывать затраты, выстраивать сервисные отношения с бизнесом, определять приоритеты развития и доказывать ценность ИТ для компании. Учет стоимости услуг помогает в принятии решений о развитии или закрытии тех или иных сервисов и делает ИТ-менеджмент более прозрачным и понятным для бизнес-руководства.

В основе парадигмы ITSM лежат такие стандарты и фреймворки, как ITIL (Information Technology Infrastructure Library), COBIT (Control Objectives for Information and Related Technologies), ISO/IEC 20000 (международный стандарт для управления ИТ-услугами), MOF (Microsoft Operations Framework) и другие. ITIL является наиболее распространённым подходом и определяет набор лучших практик по управлению ИТ-услугами, охватывающий все аспекты жизненного цикла сервисов. Эти стандарты предоставляют общую основу для построения процессов ITSM, определяя цели, процессы, функции и метрики для эффективного управления ИТ-услугами.

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

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

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

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

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

ITIL рекомендует гибко подходить к распределению ролей в управлении изменениями, учитывая организационный контекст. В небольших организациях часто происходит объединение нескольких ролей (владельца процесса, менеджера процесса, администратора изменений и председателя CAB) в одну роль менеджера изменений. В более крупных организациях эти функции распределяются между специалистами, при этом может быть отделен менеджер изменений, отвечающий за общее управление практикой, и координаторы изменений, сосредоточенные на конкретных областях. ITIL подчеркивает, что распределение ролей должно соответствовать нуждам организации, а не строго следовать шаблону, независимо от версии ITIL (V3 или ITIL4).

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

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