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

Обычно выделяются четыре уровня влияния инцидентов: 1) Максимальный уровень (критический) - когда ИТ-услуга недоступна для всего отдела или компании, что приводит к полной остановке бизнес-процессов. 2) Высокий уровень - когда несколько сотрудников сталкиваются с полным отсутствием функционала. 3) Средний уровень - когда у группы пользователей доступна только часть функционала. 4) Низкий уровень (минимальный) - когда у одного сотрудника недоступна только часть функционала ИТ-услуги. Эти уровни могут варьироваться в зависимости от принятой в организации методологии и дополнительных критериев оценки, таких как VIP-статус пользователей или критичность системы.

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

В тексте выделяются три основные траектории развития отношений между агентом изменений и компанией: 1) Отставание специалиста от скорости изменений компании ("Падшая звезда") - когда специалист не справляется с масштабами и сложностью изменений; 2) Примерно параллельное движение ("Боевой товарищ") - когда агент изменений успешно адаптируется и встроивается в процессы компании; 3) Отрыв специалиста куда-то в светлые дали ("Заряженная пружина") - когда потенциал и возможности агента изменений выше, чем текущие задачи компании.

Фактические трудозатраты следует фиксировать как можно более своевременно, идеально - сразу после завершения работы. Допустимым крайним случаем является учет один раз в конце рабочего дня. Чем дольше задержка с учетом времени, тем ниже его достоверность. Например, при учете раз в неделю искажение трудозатрат может составлять около 10% (что соответствует 4 рабочим часам в неделю), причем чаще всего данные оказываются завышенными, вероятно, из-за неосознанного стремления отразить более интенсивную работу. Своевременная фиксация времени также более эффективна, так как онлайн-учет занимает меньше времени, чем попытки вспомнить и зафиксировать пройденные события в конце недели. При правильной организации учета по 20-25 работам, учитывая, что не все сотрудники участвуют во всех работах и не выполняют все свои задачи ежедневно, на учет специалист тратит около 10 минут в день (примерно 2% рабочего времени), а линейный руководитель - около 5% рабочего времени на контроль данных.

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

Для повышения точности данных, вводимых пользователями, необходимо использовать интерактивные элементы, такие как выпадающие списки, чекбоксы и автозаполнение. Например, вместо того чтобы просить пользователя ввести модель принтера, следует предоставить список всех доступных моделей, чтобы исключить ошибки в написании. Также полезны подсказки и шаблоны для текстовых полей. Если данные могут быть получены автоматически через систему (например, модель принтера по его MAC-адресу), это следует реализовать, чтобы минимизировать ручной ввод. Дополнительно можно провести обучение пользователей, чтобы они понимали важность ввода корректных данных.

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

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

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